FW: WebDAV and 404-handling

Accidentally dropped the list from response.

> -----Original Message-----
> From: Eriksson, Michael 
> Sent: Thursday, January 16, 2003 6:46 PM
> To: 'Julian Reschke'
> Subject: RE: WebDAV and 404-handling
> 
> 
> Julian,
> 
> > 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.
> 
> > 
> > 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
> 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
> status as appropriate.  Thus your statement is probably
> compatible with the fact that the error pages mechanism
> changes the original status.
> 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.
> 
> >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.)
> 
> Michael
>

Received on Thursday, 16 January 2003 12:55:03 UTC