Another user who is involuntarily stuck on the list

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