Re: 3xx vs RFC2518 vs redirect-ref spec

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