W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: HTTP Status 308 (Permanent Redirect)

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 13 Feb 2014 12:12:13 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <BA58C5EA-8155-424A-BB1E-81651527CEB6@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>
LGTM.

On 6 Feb 2014, at 11:28 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

> Hi there,
> 
> this status code was defined in draft-reschke-http-status-308-07 and approved as Experimental RFC almost two years ago:
> 
>  <https://datatracker.ietf.org/doc/draft-reschke-http-status-308/>
> 
> It's been sitting in the RFC Editor queue since then, waiting for the HTTPbis specs to arrive.
> 
> When it was written, the status code description was consistent with the HTTPbis P2 draft that was current back then -- see <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.7.3>.
> 
> Since then, the definition was rephrased quite a bit, and I believe it would be good to update the prose in the 308 definition accordingly in order to avoid confusion.
> 
> The proposed diffs are here: <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest-from-previous.diff.html> (which also contains some more changes due to HTTPbis P2 section number changes).
> 
> The full text of the section would change from:
> 
>> 3.  308 Permanent Redirect
>> 
>>   The target resource has been assigned a new permanent URI and any
>>   future references to this resource SHOULD use one of the returned
>>   URIs.  Clients with link editing capabilities ought to automatically
>>   re-link references to the effective request URI (Section 5.5 of
>>   [draft-ietf-httpbis-p1-messaging]) to one or more of the new
>>   references returned by the server, where possible.
>> 
>>   Caches MAY use a heuristic (see [draft-ietf-httpbis-p6-cache],
>>   Section 2.3.1.1) to determine freshness for 308 responses.
>> 
>>   The new permanent URI SHOULD be given by the Location field in the
>>   response ([draft-ietf-httpbis-p2-semantics], Section 10.5).  A
>>   response payload can contain a short hypertext note with a hyperlink
>>   to the new URI(s).
>> 
>>      Note: This status code is similar to 301 Moved Permanently
>>      (Section 7.3.2 of [draft-ietf-httpbis-p2-semantics]), except that
>>      it does not allow rewriting the request method from POST to GET.
> 
> to:
> 
>> 3.  308 Permanent Redirect
>> 
>>   The 308 (Permanent Redirect) status code indicates that the target
>>   resource has been assigned a new permanent URI and any future
>>   references to this resource ought to use one of the enclosed URIs.
>>   Clients with link editing capabilities ought to automatically re-link
>>   references to the effective request URI (Section 5.5 of
>>   [draft-ietf-httpbis-p1-messaging]) to one or more of the new
>>   references sent by the server, where possible.
>> 
>>   The server SHOULD generate a Location header field
>>   ([draft-ietf-httpbis-p2-semantics], Section 7.1.2) in the response
>>   containing a preferred URI reference for the new permanent URI.  The
>>   user agent MAY use the Location field value for automatic
>>   redirection.  The server's response payload usually contains a short
>>   hypertext note with a hyperlink to the new URI(s).
>> 
>>   A 308 response is cacheable by default; i.e., unless otherwise
>>   indicated by the method definition or explicit cache controls (see
>>   [draft-ietf-httpbis-p6-cache], Section 4.2.2).
>> 
>>      Note: This status code is similar to 301 (Moved Permanently)
>>      ([draft-ietf-httpbis-p2-semantics], Section 6.4.2), except that it
>>      does not allow changing the request method from POST to GET.
> 
> Although this hasn't been a WG work item, it would be awesome if a few people could review the proposed change and give feedback about whether this would be an acceptable change prior to publication as RFC.
> 
> Best regards, Julian
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 13 February 2014 01:12:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC