RE: WebDAV and 404-handling

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: 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:
>
> 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 11:52:08 UTC