- From: Eriksson, Michael <Michael.Eriksson@bauer-partner.com>
- Date: Fri, 17 Jan 2003 13:15:13 +0100
- To: <w3c-dist-auth@w3.org>
Hi, could someone give Mark a hand? 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 >> >> > >
Received on Friday, 17 January 2003 07:15:15 UTC