- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 04 Nov 2011 09:27:40 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: Yves Lafon <ylafon@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 2011-11-03 04:45, Mark Nottingham wrote: > > 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). > ... I think *some* prose around this is useful, as otherwise the same questions continue to come up again and again. *If* we believe that the decorate-with-Cache-Control thingy works, we should say so. If we do not, we could shorten the note. Best regards, Julian
Received on Friday, 4 November 2011 08:28:17 UTC