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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 17 Oct 2003 21:00:56 +0200
To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEHEINAA.julian.reschke@gmx.de>

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

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

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Saturday, October 18, 2003 8:45 AM
> To: 'Julian Reschke'; w3c-dist-auth@w3.org
> Subject: RE: redirect ref spec, update on issue lc-85-301 
> 
> 
> > 
> > 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
> 
> 
Received on Friday, 17 October 2003 15:01:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:05 GMT