- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Thu, 9 Oct 2003 12:46:27 -0400
- To: w3c-dist-auth@w3.org
- Message-ID: <OFF6CBD80B.D1C39432-ON85256DBA.005B87E5-85256DBA.005C252E@us.ibm.com>
For (1), I could go either way on this, but if we did give a client
a way to say this, I suggest that it be in the form of a request DAV
header, and that we introduce a symbol that means "the redirect-ref
standard", e.g. something like:
DAV: 1, 2, redirect
Note that I am bundling this into the general "I understand the
redirect spec" token, since I'd rather not introduce a new token for
each detailed bit of functionality.
For (2), Julian's suggestion is fine, but shouldn't the Location
node be optional (i.e. "Location?").
Cheers,
Geoff
Julian wrote on 10/09/2003 11:31:29 AM:
>
> 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 12:46:27 UTC