RE: WebDAV and 404-handling

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.

> ...
> 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.
> ...

In which case you shouldn't use the mapping.

> ...
> > > 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.)
> ...

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

Julian

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

Received on Friday, 17 January 2003 06:19:01 UTC