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

RE: WebDAV and 404-handling

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 16 Jan 2003 17:51:32 +0100
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEGLGDAA.julian.reschke@gmx.de>


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.


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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eriksson, Michael
> Sent: Thursday, January 16, 2003 5:21 PM
> 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:
> 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 11:52:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC