Subject: 3xx vs RFC2518 vs redirect-ref spec

From: "Julian Reschke" <[email-masked]>
Date: Thu, 9 Oct 2003 17:31:29 +0200

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 9 Oct 2003 12:46:27 -0400

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

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 9 Oct 2003 18:54:58 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Geoffrey M Clemm
> Sent: Thursday, October 09, 2003 6:46 PM
> To: [email-masked]
> Subject: Re: 3xx vs RFC2518 vs redirect-ref spec
>
>
>

Well, I'd rather not do that unless it's in the base spec (RFC2518bis). The
redirect draft already defines a new header, so that one can easily be
used....

> node be optional (i.e. "Location?").

Of course :-)

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 9 Oct 2003 13:56:04 -0400

My first choice is to get this in the base spec, since I think it is
a bug that the server can register what options it supports, but a
client cannot.

I could live with Julian's approach, but I'd rather not, since I think
this is a general problem that merits a clean extensible solution
(as opposed to a one-off hack :-).

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 9 Oct 2003 20:00:05 +0200

OK,

so we probably should put it onto the issues list (so that it doesn't get
lost).

Julian

> -----Original Message-----
> Sent: Thursday, October 09, 2003 7:56 PM
> To: [email-masked]
> Subject: RE: 3xx vs RFC2518 vs redirect-ref spec
>
>
>