Re: Another user who is involuntarily stuck on the list

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