Subject: FW: WebDAV and 404-handling

From: "Eriksson, Michael" <[email-masked]>
Date: Thu, 16 Jan 2003 18:54:59 +0100

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
>

---

From: "Eriksson, Michael" <[email-masked]>
Date: Thu, 16 Jan 2003 18:59:06 +0100

Lisa,

> 
> The IE method of doing HEAD then PUT is a timing-dependent solution to
> preventing unintended overwrites.

Well, I usually just assume that Microsoft does it the wrong
way. This is a good, time-saving heuristic :-)

> As such, it's about as dependable as
> the rhythm method in preventing unintended pregnancies.
I am not familiar with that one...

> The recommended way to prevent overwrite on PUT is to put the header
> "If-None-Match: *" on the request.   See for example
> http://www.w3.org/1999/04/Editing/.
> 
> This may not solve your problem because it sounds like you have control
> over the server but not the client.

Partially true, because I could change the server side.
Doing so would however bring other disadvantages. (Such as
having to maintain an extra version of a third party
component.) IE is over course completely out of my hands.
Also, there is no guarantee that the end user actually uses
IE and not e.g Cadaver.

> I'm confused by your statement that
> the server is "correct" in this. I would think the server ought to use a
> 404 Not Found response, with or without a body containing more detail,
> in response to a HEAD.  
See my previous response to Julian, which clarifies this
statement.

> I know Tomcat can be extended with a servlet to respond with a 404 to a
> HEAD to a non-existent file (with or without a body).  Xythos WebFile
> Server does this for example.

Tomcat per se handles non-existant files in the usual
maner. The problem is in the error pages, which are a part
of the servlet specification. (S. my email to Julian again.)

Michael

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 16 Jan 2003 23:11:02 +0100

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.
>

No, it doesn't. As long as the error page isn't sent out with a 2xx status.
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
> 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".

> 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.

> changes the original status.

If it does, it's broken. As far as I can tell, it doesn't.

> the extension with the servlet specification people.

I might if you can point me more precisely to that discussion.

> has a non-neglectable impact on the client behaviour.)

In general, the response body that was produced upon error never should be
replaced. If there's a mechanism with canned, multi-lingual error pages, it
should only be used if the real server code didn't produce it's own response
body.

For instance, replacing the response body for 403 or 409 responses almost
certainly will break WebDAV/deltaV interoperability.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Eriksson, Michael" <[email-masked]>
Date: Fri, 17 Jan 2003 11:39:06 +0100

Thank you Geoff.  With the information from you and Julian,
I can procede with simply re-resetting the status to 404.
(For the time being at least.)

> 
> Currently, there is no standard WebDAV content for a 404
> body, so you can replace that body without violating
> the WebDAV standard.  Probably the safest thing to do is to
> only substitute the error page if the 404-body is
> empty.

[snip]

Michael