Re: #312: should there be a permanent variant of 307?

On 03/11/2011, at 6:34 AM, Julian Reschke wrote:

> On 2011-10-29 01:12, Mark Nottingham wrote:
>> 
>> On 29/10/2011, at 2:35 AM, Yves Lafon wrote:
>> 
>>> On Thu, 27 Oct 2011, Julian Reschke wrote:
>>> 
>>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/312>
>>>> 
>>>> So now that we have allowed UAs to rewrite a 301 POST to GET (see<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>), the spec doesn't have a permanent redirect that always preserves the method.
>>>> 
>>>> (We *do* have the equivalent for temporary redirects: 307).
>>>> 
>>>> So...:
>>>> 
>>>> 1) Is this a problem?
>>> 
>>> First thing is... was 301 ever used to change entries in a bookmark or a link in a page? If not, then it's not a problem worth adding a new status code.
>> 
>> +1
>> 
>>> A 307 with a long enough cache time should be enough to redirect people.
>>> If it is, then 2a would be the best option (in another doc)
>> 
>> But then you have a deployment problem; it won't be backwards-compatible with most existing browsers (i.e., the redirect won't work), so it'll never get out there.
>> 
>> AFAICT the only way to deploy would be to mint a new CC directive that means "forever" -- and we've already discussed that and decided not to go that way, IIRC.
>> 
>> My personal .02 - I think this is close with no action, or at most a bit of prose in 307.
>> ...
> 
> OK, here's something we could say in the text about 307:
> 
>      Note: this status code is similar to 302 Found, except that it
>      does not allow rewriting the request method from POST to GET.
>      There is no equivalent counterpart for 301 Moved Permanently.
>      Servers that need a "permanent" variant of this status code can
>      specify it's lifetime using Cache-Control (Section 3.2 of
>      [Part6]), for instance by using "Cache-Control: max-age=315360000"
>      (an expiry time ten years in the future).
> 

+0 -- not against it, not sure it's really necessary (but happy to put it in if that moves us forward).


--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 3 November 2011 03:46:11 UTC