Subject: RE: WebDAV and 404-handling

From: "Eriksson, Michael" <[email-masked]>
Date: Fri, 17 Jan 2003 11:38:11 +0100

Julian,

there seems to be a couple of misunderstandings, due to the
fact that I have not explained the error pages mechanism
with enough detail.  This seemed reasonable, since I had not
counted on a discussion of the background part of my
original email.

Anyway (to my current understanding):
Tomcat _does_ handle e.g. 404 in a spec compliant maner per
default.  However, to simplify and centralize error handling
Tomcat (or probably the Catalina sub-component) supports an
error page mechanism defined by Suns servlet specification.

This mechanism allows for defining certain resources
(normally JSPs that provide dynamic content) that are
_always_ returned in case a certain status code (e.g. 404)
occurs. They thus effectively replace the default error
pages sent by the server.

The Tomcat implementation, which is claimed to be correct,
automatically removes the status code. The correctness of
this step depends on the servlet specification, _not_ the
HTTP specification.

The error page (error resource might be a more appropriate
name) can however explicitly change the status code to a
suitable value.  Here there might be a clash with the HTTP
specification, if the original status code is not reset.

The body of the original response (as generated by e.g. the
WebDAV component) is however lost.

Also note that I am using the term "error page" in the very
specific sense of the above discussion. I have probably not
emphasized that I do not mean "error page" in a general
sense clearly enough.

> > ..
> >
> > > I think the assumption that there's a difference between "user-oriented
> > > (HTML through HTTP)" and "software-oriented (WebDAV)" output is
> > wrong in the
> > > first place.
> >
> > You are absolutely right. This is also not my assumption,
> > but an assumption that is most often present in a "normal"
> > HTML/HTTP context.  The error page mechanism, in combination
> > with an error page that has a nice message like:
> >
> > Oops, we screwed up.
> > Please contact us per email at ........
> >
> > also adhers to this assumption.
> 
> No, it doesn't. As long as the error page isn't sent out with a 2xx status.

This is what happens per default with error pages. I.e. the
error page has to explicitly set the status to 404.

Even if the status _is_ set a client that relies on the
content of the original body is in difficulties -- because
somewhere along the line the assumption was made that it was
safe to send a user oriented body.

> You can and should send out a message body (explaining the error condition)
> upon errors (check RFC2616). However this doesn't mean that the status
> itself should be hidden.
> 
> > > GET on a non-mapped URL should *always* return a 404 status (no matter
> what
> > > the "type" of the user agent is).
> >
> > I tend to agree (if we take "non-mapped URL" to exclude e.g.
> > permanently moved items) and I will have to check if we
> 
> In which case it would be a mapped URL (in WebDAV-speak) which identifies a
> "redirect resource".
> 
> > should generally change our error pages to pass the status
> > on.
> >
> > However, the correct behaviour of the error page mechanism
> > is (judging from the answers to several bug reports that I
> > have seen in the tomcat archives) _not_ to pass the status
> > on.  The individual error pages can (should?) then set the
> 
> That's plain wrong. I just checked with Apache/moddav (www.apache.org) and
> Tomcat 4.x (greenbytes.de:81), and both return both a 404 status *and* a
> message body for unmapped URLs.

See above. (But Apache/moddav is completely separate from
Tomcat.)

> > status as appropriate.  Thus your statement is probably
> > compatible with the fact that the error pages mechanism
> > changes the original status.
> 
> If it does, it's broken. As far as I can tell, it doesn't.

See above.

> > If you see a problem here, e.g. that status codes (or 404s)
> > should never ever be changed, you might want to discuss it
> > with the tomcat people (s. jakarta.apache.org/tomcat) or in
> > the extension with the servlet specification people.
> 
> I might if you can point me more precisely to that discussion.

http://www.mail-archive.com/[email-masked]/msg38700.html
(Jump to the most interesting part of the somewhat heated thread.)

http://issues.apache.org/bugzilla/show_bug.cgi?id=15406
(Bug report.)

[snip]

Michael

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 17 Jan 2003 12:18:29 +0100

Michael,

I've been looking at the servlet spec (2.4) and the bug reports you cited.
As far as I understand the topic, the servlet engine allows you to specify
specfic URIs for error pages, but as you do so, it's your own job to ensure
that the proper HTTP status is sent. So if you map 404 response to an error
page, that error page should send out an HTTP status of 404 as well:

"If you point at a webapp resource that *itself* returns a 200 status
(which is the default behavior for static resources served by the
file-serving servlet, and which is what JSP pages will return unless you
do something different inside them), a 200 is what you should see in the
final response to the client.

If you want something different, map your error page handlers to a servlet
that does something different."

I agree though that this mechanism makes it ridicoulously easy to produce
broken HTTP responses.

> ...
> ...

In which case you shouldn't use the mapping.

> ...
> ...

Yes, that's why I tested *both*.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760