- From: Yves Lafon <ylafon@w3.org>
- Date: Fri, 17 Jan 2003 13:21:43 +0100 (MET)
- To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
- cc: w3c-dist-auth@w3.org
On Fri, 17 Jan 2003, Eriksson, Michael wrote: > > Hi, > > could someone give Mark a hand? I took care of it. Thanks, > See below. > > Michael > > > -----Original Message----- > > From: Mark Kline [mailto:mkline@markklineskarate.com] > > Sent: Friday, January 17, 2003 1:08 PM > > To: Eriksson, Michael > > Subject: Re: WebDAV and 404-handling > > > > > > Michael, > > > > The message was for anyone who could send it to the sys admin since I > > cannot access the list, but am somehow on it. I have sent emails > > before and you are the only one who has replied...Thanks! > > > > this email address is somehow on your list. Please have it removed. > > > > Mark > > On Friday, January 17, 2003, at 05:49 AM, Eriksson, Michael wrote: > > > > > Mark, > > > > > > was this message actually intended for me or the list? > > > If it _is_ for me, I will need more details to take any > > > kind of action. > > > If not you will have to resend it to the list. > > > > > > Michael > > >> -----Original Message----- > > >> From: Mark Kline [mailto:mkline@markklineskarate.com] > > >> Sent: Friday, January 17, 2003 11:44 AM > > >> To: Eriksson, Michael > > >> Subject: Re: WebDAV and 404-handling > > >> > > >> > > >> How about explaining the lawsuit that I am going to bring to your > > >> company for putting me on this list. THIS IS NO JOKE! I > > WANT TO BE > > >> REMOVED IMMEDIATELY FROM THIS LIST. I DO NOT WORK FOR > > YOUR COMPANY. > > >> > > >> PLEASE CONTACT YOUR SYSTEM ADMINISTRATOR AND FIX THIS NOW! > > THIS HAS > > >> BEEN GOING ON FOR A FEW MONTHS NOW!! > > >> > > >> MARK KLINE > > >> On Friday, January 17, 2003, at 05:38 AM, Eriksson, Michael wrote: > > >> > > >>> > > >>> 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 > >> > >> > > > > > -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Friday, 17 January 2003 07:21:45 UTC