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