- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 9 Oct 2003 17:31:29 +0200
- To: <w3c-dist-auth@w3.org>
Hi, rfc2518bis currently states: -- 12.1 Responses requiring Location in Multi-Status The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax does not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. -- There are two issues here that I'd like to be resolved both in rfc2518bis and draft-ietf-webdav-redirect-ref: 1) Are servers allowed not to report redirects as 3xx? I think I myself made the proposal to allow this because in practice returning 3xx responses in multistatus breaks a lot of clients (for instance, the Microsoft Webfolder client). However, if we allow this, there should be an explicit way for a client to force the server to return 3xx responses (that would then be defined in draft-ietf-webdav-redirect-ref). 2) I think we also should say that if a 3xx is returned, that the Location information must be returned as well. draft-ietf-webdav-redirect-ref uses a pseudo-property for that, but during Last Call in 2000 this was already discussed and it seems that there was a consensus to just extend the DAV:response element instead. So here's my proposal: a) Allow servers to report redirects with a 200 status. Thus will cause redirects to appear as regular resources, however an attempt to GET them will result in a HTTP redirect (which indeed will work fine with the MS webfolder client). b) In draft-ietf-webdav-redirect-ref, extend "Apply-To-Redirect-Ref" to have the values "T" or "F". In presence of this header, require the server not do to the 2xx workaround described in a). ("F" would mean that the server MUST NOT apply the request to the redirect target but also signals that the client knows about the various extensions in the redirect spec) c) In both RFC2518bis and draft-ietf-webdav-redirect-ref, define an extension element for DAV:response holding the Location header for the redirect, such as: <!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?, location) > <!ELEMENT location (href)> (this takes care of the various issues inherent in "pseudo" properties). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 9 October 2003 11:34:36 UTC