W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Issue 160 (Redirects and non-GET methods)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 19 Sep 2010 12:13:08 +0200
Message-ID: <4C95E234.1040609@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
Hi everybody,

I'd like to finally make progress on the issue above: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>. See tests at 
<http://www.mnot.net/javascript/xmlhttprequest/>.

As far as I can tell, there are two problems that need to be fixed:

1) The Notes for status 301 and 302 differ more than they should. It 
seems that user agents (mis-)behave for them the same way.

2) RFC 2616 has introduced status 307 (for doing 302 the "right way"), 
but no equivalent for 301.


The suggested fix for 1) is to allow UAs to do what they do today. 
However, it's not totally clear how far we want to go with that:

1a) We know that all major browsers rewrite the request method to GET 
when receiving a 301/302 on POST.

1b) Browsers do differ in their behavior for XmlHttpRequest, though. IE 
only rewrites POST, and leaves other methods alone. Other browsers seem 
to rewrite all methods (minus HEAD?). The fact that IE does only rewrite 
for POST suggests that breaking the RFC 2616 semantics is not needed for 
the other methods.

1c) There are other UAs that do not rewrite the method name at all, and 
indeed may be broken if they would start to do that (WebDAV clients 
getting a redirect on PROPFIND come to mind; I also see this behavior in 
Microsoft's XmlHttpRequest ActiveX control, though).

My proposal is to say SHOULD NOT change the method, except for GET which 
can be changed to POST for compatibility with broken web content (which 
should use 303 instead).

The suggested fix for 2) is to clarify that 307 can mean "permanent 
redirect" (thus be a replacement for 301) by decorating it with a 
suitable Cache-Control header. I think it would be great to have an 
example for that; either in the specification for 307, or in a separate 
subsection that we could add explaining the mess around 301/302/303/307.

Finally, given there are replacements for 301 and 302, should we 
actually deprecate these two?

Feedback appreciated,

Julian
Received on Sunday, 19 September 2010 10:13:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:25 GMT