W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

WebDAV and 404-handling

From: Eriksson, Michael <Michael.Eriksson@bauer-partner.com>
Date: Thu, 16 Jan 2003 17:21:06 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F520FFF95@dest-as20-002.int.bauer-partner.com>
To: <w3c-dist-auth@w3.org>


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

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.

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:

if already present then check with user
    if user allows

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


Michael Eriksson
Received on Thursday, 16 January 2003 11:21:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC