Subject: Issue 160 (Redirects and non-GET methods)

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Sep 2010 12:13:08 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Sep 2010 16:54:18 +0200

On 19.09.2010 12:13, Julian Reschke wrote:
> ...
> ...

This one is pretty urgent, as HTNL5 allows PUT and DELETE in HTML forms. 
Browser implementers who actually do that will have to decide what to do 
with 301s and 302s.

See related Mozilla bugzilla comment: 
<https://bugzilla.mozilla.org/show_bug.cgi?id=583288#c32>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Sep 2010 15:53:26 +0200

> <https://bugzilla.mozilla.org/show_bug.cgi?id=583288#c32>.

In the meantime, I have raised bugs against Webkit/Chromium//FF/Opera, 
pointing out that they do the method rewriting for more methods than it 
seems to be needed for, considering that IE only rewrites POST (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160> for the various 
issue links).

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 22 Sep 2010 22:42:32 +0200

> can be changed to POST for compatibility with broken web content (which  

If we make 307 the new 301/302 I'd rather we rewrite for all methods  
consistently rather than just for POST.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Sep 2010 22:50:52 +0200

On 22.09.2010 22:42, Anne van Kesteren wrote:
> On Sun, 19 Sep 2010 12:13:08 +0200, Julian Reschke
> <[email-masked]> wrote:
>> 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).
>

We can't mandate that; it would break existing non-browser uses.

We cab *allow* it for certain methods, but why allow it for more methods 
than it's needed for?

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 22 Sep 2010 22:55:11 +0200

> We cab *allow* it for certain methods, but why allow it for more methods  

Because it is more consistent and will encourage people to use that what  
actually works everywhere and for every method (if they really want that  
behavior).

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Sep 2010 23:08:21 +0200

On 22.09.2010 22:55, Anne van Kesteren wrote:
> On Wed, 22 Sep 2010 22:50:52 +0200, Julian Reschke
>> We cab *allow* it for certain methods, but why allow it for more
>> methods than it's needed for?
>

Well, it's not consistent with non-browser clients, with XmlHTTPRequest 
(ActiveX), or IE.

Also, what about HEAD? Or OPTIONS?

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Sep 2010 13:07:41 +0200

> Well, it's not consistent with non-browser clients, with XmlHTTPRequest  

Non-browser clients do not change POST either so they do not count. And  
XMLHttpRequest in IE is indeed inconsistent in how it does this.

> Also, what about HEAD? Or OPTIONS?

The same. 301/302 are effectively equivalent to 303. Seems better than  
equivalent to 307 except for POST.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 13:16:57 +0200

On 29.09.2010 13:07, Anne van Kesteren wrote:
> On Wed, 22 Sep 2010 23:08:21 +0200, Julian Reschke
>> Well, it's not consistent with non-browser clients, with
>> XmlHTTPRequest (ActiveX), or IE.
>

Why do they not count?

IE breaks the spec in fewer cases than the others, and gets away with 
it. I think that's an indication that breaking it in all cases isn't needed.

> equivalent to 307 except for POST.

Well, let's agree to disagree on that :-)

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Sep 2010 13:28:15 +0200

> it. I think that's an indication that breaking it in all cases isn't  

Agreed, but it is way more ugly than what the other browsers do in my  
opinion and might cause people to avoid using POST (in favor of CHICKEN)  
just because of this rather than simply start using 307 which will work  
everywhere.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 13:51:04 +0200

On 29.09.2010 13:28, Anne van Kesteren wrote:
> On Wed, 29 Sep 2010 13:16:57 +0200, Julian Reschke

I'm not concerned so much about new stuff; yes, we should recommend 307 
if you want method preservation.

I *am* concerned about cases where 301 and 302 *today* are used as 
described in RFC 2616 (non-browser scenarios).

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Wed, 29 Sep 2010 18:16:36 -0700

On Wed, Sep 29, 2010 at 4:51 AM, Julian Reschke <[email-masked]> wrote:
> I'm not concerned so much about new stuff; yes, we should recommend 307 if
> you want method preservation.
>
> I *am* concerned about cases where 301 and 302 *today* are used as described
> in RFC 2616 (non-browser scenarios).

Would a reasonable solution be to say that the user agent MAY change
the method to GET.  Servers that desire predictable behavior from user
agents w.r.t. method rewriting SHOULD use 303 or 307.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Sep 2010 09:46:59 +0200

> agents w.r.t. method rewriting SHOULD use 303 or 307.

Well, it may not change HEAD to GET, because that screws up the message 
framing in the response.

So, my preference still is MAY rewrite POST to GET, and SHOULD use 307 
when rewriting POST to GET would be a problem.

Best regards, Julian