RE: WebDAV and 404-handling

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/tomcat-dev@jakarta.apache.org/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

Received on Friday, 17 January 2003 05:38:16 UTC