- From: Eriksson, Michael <Michael.Eriksson@bauer-partner.com>
- Date: Thu, 16 Jan 2003 17:21:06 +0100
- To: <w3c-dist-auth@w3.org>
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:21:11 UTC