RE: WebDAV and 404-handling

The IE method of doing HEAD then PUT is a timing-dependent solution to
preventing unintended overwrites.  As such, it's about as dependable as
the rhythm method in preventing unintended pregnancies.

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

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.

lisa

> -----Original Message-----
> From: Eriksson, Michael [mailto:Michael.Eriksson@bauer-partner.com]
> Sent: Thursday, January 16, 2003 8:21 AM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV and 404-handling
> 
> 
> Hi,
> 
> I have a problem with the integration of a pre-existing
> WebDAV component in a web-application.  (As in Suns
> servlet specification.)
> 
> This problem, outlined below, leads to the following
> questions:
> 
> 1) Is the body of a 404ed response ever relevant for WebDAV?
> 2) What about other error codes (as opposed to status
>    codes indicating non-errors)?
> 3) Do you see any other potential problems from the
>    discussion below?
> 
> The only interesting cases are status codes in the
> normal HTTP header. A status code wrapped in an XML-tag
> in the body is not relevant for my problem. Further
> status codes not explicitly defined in the
> HTTP-specification are (probably) irrelevant.
> 
> Background:
> Web-applications allow for defining error pages
> (normally JSPs) which on e.g. a 404 override the normal
> server output. This gives an easily configurable and
> central handling of what the end users actually sees.
> 
> In the specific case of WebDAV this is, however,
> somewhat problematic.  For instance, consider the
> following (client side) upload procedure:
> 
> HEAD
> if already present then check with user
>     if user allows
>         PUT
>     endif
> else
>     PUT
> endif
> 
> (This is what happens with my version of Internet
> Explorer judging by the output of an http sniffer.)
> 
> Since the recent addition of the above mentioned error
> pages I have the problem that HEAD will no longer yield
> a 404. The error pages come in between, and thus the
> user is queried even if no previous entry is present.
> 
> As an experimental workaround I have altered the
> corresponding error page to explicitly send a 404 if the
> request was directed to the WebDAV-component.  This
> takes care of the problem above, but is still
> potententially dangerous, since the body/content of the
> original response is lost. (In the case of WebDAV any
> XML-tags specifying details.) Additionally, this might
> not work for other status codes.
> 
> As a side-note, to prevent misunderstandings: The
> behaviour of the server, tomcat, is correct. The
> problems originate in a principal clash between
> user-oriented (HTML through HTTP) and software-oriented
> (WebDAV) output.
> 
> Regards,
> 
> Michael Eriksson
>

Received on Thursday, 16 January 2003 12:41:00 UTC