Subject: WebDAV and 404-handling

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

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

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 16 Jan 2003 17:51:32 +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.

GET on a non-mapped URL should *always* return a 404 status (no matter what
the "type" of the user agent is). And it's perfectly legal to return a
response body for a 404.

Julian

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eriksson, Michael
> Sent: Thursday, January 16, 2003 5:21 PM
> To: [email-masked]
> Subject: WebDAV and 404-handling
>
>
>
> Hi,
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 16 Jan 2003 09:40:50 -0800

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

> From: Eriksson, Michael [mailto:[email-masked]]
> Sent: Thursday, January 16, 2003 8:21 AM
> To: [email-masked]

---

From: Chris Knight <[email-masked]>
Date: Thu, 23 Jan 2003 11:44:04 -0800

> the rhythm method in preventing unintended pregnancies.

:^)

> http://www.w3.org/1999/04/Editing/.

And, as we discussed at the WG Interim Mtg, the use of the "Expect" HTTP 
header, something we should be actively encouraging development of as 
it's in the HTTP/1.1 as it would report an unintended overwrite before 
the body of the message is sent. Correct?