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

3xx vs RFC2518 vs redirect-ref spec

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Thu, 9 Oct 2003 17:31:29 +0200
To: <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEDAIMAA.julian.reschke@greenbytes.de>


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

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


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 9 October 2003 11:34:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC