- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 16 Jan 2003 23:11:02 +0100
- To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>, <w3c-dist-auth@w3.org>
Michael, > .. > > > 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. 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. > 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. > 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. > >And it's perfectly legal to return a response body for a 404. > > It is. However, if WebDAV sends one body and the error page > overwrites it then the "wrong" contents reach the > WebDAV-client. This is exactly the problem that provoked my > questions. I.e does WebDAV ever use 404-bodies for > "important" data? (Defining "important" as something that > has a non-neglectable impact on the client behaviour.) In general, the response body that was produced upon error never should be replaced. If there's a mechanism with canned, multi-lingual error pages, it should only be used if the real server code didn't produce it's own response body. For instance, replacing the response body for 403 or 409 responses almost certainly will break WebDAV/deltaV interoperability. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 16 January 2003 17:11:41 UTC