Subject: redirect ref spec, update on issue lc-85-301

From: "Julian Reschke" <[email-masked]>
Date: Mon, 13 Oct 2003 17:34:45 +0200

Hi,

one of the (many) open issues for the redirect spec is the support for
additional response codes, initially reported by Jim.

I just re-read RFC2616's section on 3xx status codes, and here's my summary
and a proposal how to resolve this:

HTTP seems to distinguish the following use cases:

(a) permanent redirect (301),
(b) temporary redirect (302 or 307),
(c) redirect to a GET location after POST (303) and
(d) agent-driven negotiation (300).

Among these, (a) and (b) seem to be well understood, so we should support
both. (c) doesn't seem to be applicable. (d) may become interesting when
user agents start supporting it, so the spec should be flexible enough to
support a feature extension for that.

For now I propose that the client is able to specify the redirection type as
a resource type, such as "DAV:permanent-redirect-reference" and
"DAV:temporary-redirect-reference". This spec would only define the
behaviour for these two resource types and would allow future extensions
using new resource types and suggested response codes.

(See
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-lat
est.html#rfc.issue.lc-85-301>)

Regards,

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 14 Oct 2003 06:21:47 -0400

This would be fine with me.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 17 Oct 2003 23:45:23 -0700

> 
> For now I propose that the client is able to specify the 
> redirection type as a resource type, such as 
> "DAV:permanent-redirect-reference" and 
> "DAV:temporary-redirect-reference". This spec would only 
> define the behaviour for these two resource types and would 
> allow future extensions using new resource types and 
> suggested response codes.
> 

What's the use case for this functionality.  How would a user
creating a link decide whether this was a permanent or a temporary
redirect link?  Is anybody actually planning to implement a 
client that would care which one it was creating?  

If there aren't implementation plans, use case, etc, then the
KISS principle suggests that we pick one. Since redirect resources
are in fact permanent until deleted (the temporariness is 
completely unknown), I see no reason why they 
wouldn't all be the same kind of redirect resource.

Before we chose one HTTP response or another, it would be good 
to know whether HTTP clients behave differently. I have no data
on this.  

lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 17 Oct 2003 21:00:56 +0200

Lisa,

HTTP is very clear about what it means:

- Temporary: follow the link, but keep accessing *this* URL
- Permanent: follow the link, and forget about the original location

Julian

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Saturday, October 18, 2003 8:45 AM
> To: 'Julian Reschke'; [email-masked]
> Subject: RE: redirect ref spec, update on issue lc-85-301 
> 
> 
> >

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 18 Oct 2003 00:10:35 -0700

This is indisputable, but that doesn't answer my questions.  
 - How do browsers in fact behave differently?  
 - What is the use case for creating different redirect resource types?

Lisa
> From: Julian Reschke [mailto:[email-masked]] 
> Sent: Friday, October 17, 2003 12:01 PM
> To: Lisa Dusseault; 'Julian Reschke'; [email-masked]
> > What's the use case for this functionality.  How would a 
> user creating 
> > a link decide whether this was a permanent or a temporary redirect 
> > link?  Is anybody actually planning to implement a client 
> that would 
> > care which one it was creating?
> > 
> > If there aren't implementation plans, use case, etc, then the KISS 
> > principle suggests that we pick one. Since redirect 
> resources are in 
> > fact permanent until deleted (the temporariness is completely 
> > unknown), I see no reason why they wouldn't all be the same kind of 
> > redirect resource.
> >

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 17 Oct 2003 21:47:09 +0200

Lisa,

I don't think it's up to me to answer that. The purpose of the Redirect Ref
spec is

1) to define how existing redirects behave inside WebDAV collections and

2) how to author redirects.

The HTTP spec has decided to distinguish between these types, and therefore
it makes sense to reflect that distinction in the redirect ref spec as well.
I imagine that browsers should remember "how they got" to the URL when the
user decides to bookmark the URL.

This feature was requested during the Last Call in spring 2000, and it seems
that there was WG consensus to add that (at least this is what the issues
list says). As storing a type seems to be trivial when the target URL needs
to be stored anyway, and as Apache indeed distinguishes between those types,
I feel it makes sense to have it authorable as well.

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, October 18, 2003 9:11 AM

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 17 Oct 2003 15:51:45 -0400

I agree with Julian's rationale for adding this distinction.
This is just modeling the behavior defined by the existing standard,
not introducing new behavior.

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Sun, 19 Oct 2003 18:42:53 -0700

> not introducing new behavior.

+1

I agree with Geoff on this issue.

- Jim