Subject: #160: Redirects and non-GET methods

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 21:16:51 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>

I've just tested the latest iterations of the browsers, with the following results:

• Safari/533.21.1 - all 301, 302, 307 rewritten to GET; 303 methods are preserved
• Firefox/5.0.1 - all 301, 302 rewritten to GET; 303 and 307 methods are preserved
• Chrome/14.0.814.0 - all 301, 302 rewritten to GET; 303 and 307 methods are preserved
• Opera/11.50 - all 301, 302 rewritten to GET; 303 methods are preserved; 307 tests crash the browser
• MSIE/9.0 (latest) - all 301, 302 methods preserved except POST (changed to GET); all 303, 307 methods are preserved

So, many browsers rewrite many methods to GET on 301 and 302. whereas most browsers preserve methods on 303 and 307*. 

We *could* codify this practice. However, as Julian notes in the bug, the fact that IE doesn't rewrite anything except POST is an existence proof (and a fairly large one) that it's workable to not rewrite the method on non-POST methods.

So, I'm inclined to agree that we could address this by changing 301 an 302 to note that POST is rewritten to GET; it's a smaller change, although it would require changes in more browsers.

Thoughts? Especially from browser people?

* Note that this doesn't include HEAD consistently, because HEAD support in XHR seems... spotty. However, where it was tested, it seems to be rewritten to GET.

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sun, 17 Jul 2011 22:31:45 +0200

On Sun, 17 Jul 2011 13:16:51 +0200, Mark Nottingham <[email-masked]> wrote:
> So, many browsers rewrite many methods to GET on 301 and 302. whereas  
> most browsers preserve methods on 303 and 307*.

Do you mean they have incorrect behavior for 303 or that they rewrite it  
to GET as they should?

> Thoughts? Especially from browser people?

No real preference, but I would expect us to stay aligned with  
WebKit/Gecko.

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

---

From: Adam Barth <[email-masked]>
Date: Sun, 17 Jul 2011 16:37:01 -0700

> Thoughts? Especially from browser people?

w.r.t. Chrome's behavior, specifically, our intent was to match
Firefox, which it looks like we've succeeded at.

>From the table above, I would recommend that Safari change to not
rewrite 307 because that seems to both violate the intent of 307 and
to align better with other user agents.  With that change (modulo
crashes!), all the non-IE browsers would behave the same way, which is
a collectively stable equilibrium that I wouldn't recommend
disrupting.

All that said, GET and POST are vastly more common for browsers to
handle than other methods.  Having reasonable requirements for GET and
POST would be a welcome step forward.

Adam

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 18 Jul 2011 14:21:21 +1200

On Sun, 17 Jul 2011 16:37:01 -0700, Adam Barth wrote:
> On Sun, Jul 17, 2011 at 4:16 AM, Mark Nottingham wrote:
>> • MSIE/9.0 (latest) - all 301, 302 methods preserved except POST 
>> (changed to GET); all 303, 307 methods are preserved
>>
>> So, many browsers rewrite many methods to GET on 301 and 302. 
>> whereas most browsers preserve methods on 303 and 307*.
>>
>> We *could* codify this practice. However, as Julian notes in the 
>> bug, the fact that IE doesn't rewrite anything except POST is an 
>> existence proof (and a fairly large one) that it's workable to not 
>> rewrite the method on non-POST methods.

 This MSIE handling of 301 is a big problem in some installations. To 
 the point that they are migrating their customers away from MSIE just to 
 get the Firefox/Chrome behaviour.

 While the proposed 428 status will help in most of these cases, the 
 browser hiding of 4xx reply entity on certain methods currently causes 
 more of a hindrance there than 301 does. The nasty hack at present is to 
 301 redirect to a location which does 428 on the followup GET.

>>
>> So, I'm inclined to agree that we could address this by changing 301 
>> an 302 to note that POST is rewritten to GET; it's a smaller change, 
>> although it would require changes in more browsers.
>>

 Even just idempotent / non-idempotent separation would be great. That 
 also leaves it open for consistency with future methods.

 AYJ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2011 09:03:40 +0200

On 2011-07-18 01:37, Adam Barth wrote:
> On Sun, Jul 17, 2011 at 4:16 AM, Mark Nottingham<[email-masked]>  wrote:

+1.

> a collectively stable equilibrium that I wouldn't recommend

I intend to submit a patch for Firefox restricting the method rewriting 
to POST.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2011 09:05:56 +0200

On 2011-07-18 04:21, Amos Jeffries wrote:
> ...
> This MSIE handling of 301 is a big problem in some installations. To the
> point that they are migrating their customers away from MSIE just to get
> the Firefox/Chrome behaviour.
> ...

How so? Why don't they fix their sites? Details, please.

> also leaves it open for consistency with future methods.

That doesn't work, as given a new method name, you don't know whether 
it's idempotent or not.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2011 17:17:58 +1000

On 18/07/2011, at 6:31 AM, Anne van Kesteren wrote:

> Do you mean they have incorrect behavior for 303 or that they rewrite it to GET as they should?

Sorry, they rewrite as they should.

Cheers,

---

From: Yves Lafon <[email-masked]>
Date: Mon, 18 Jul 2011 05:23:34 -0400 (EDT)

On Sun, 17 Jul 2011, Mark Nottingham wrote:

> ? Safari/533.21.1 - all 301, 302, 307 rewritten to GET; 303 methods are preserved
> ? Firefox/5.0.1 - all 301, 302 rewritten to GET; 303 and 307 methods are preserved
> ? Chrome/14.0.814.0 - all 301, 302 rewritten to GET; 303 and 307 methods are preserved
> ? Opera/11.50 - all 301, 302 rewritten to GET; 303 methods are preserved; 307 tests crash the browser
> ? MSIE/9.0 (latest) - all 301, 302 methods preserved except POST (changed to GET); all 303, 307 methods are preserved
>

Note that the results above are for the XHR-based test.
I tried 307 for POST "natively"
* For Opera/11.50 POST -> 307, popup to chose to redirect while preserving
   the method.
* For Safari 5.0.5 (6533.21.1), POST redirected without a prompt to
   another POST on the new URI.
* Firefox/5.0.1 redirect 307 preserving the method, and warn the user.

So we have different results for the same browser whether or not it's 
using XHR..

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2011 20:54:20 +1000

> * Firefox/5.0.1 redirect 307 preserving the method, and warn the user.

How are those different (besides not crashing Opera, of course)?

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 18 Jul 2011 23:02:09 +1200

> How so? Why don't they fix their sites? Details, please.

301 - Portals enforcing policy of no unencrypted content past the border 
and bouncing the http:// requests to https:// at the gateway.
  They require all inbound http:// get redirected to https:// without 
bothering the user. Method remaining unchanged through the redirect. 301 
is perfect here, as the domain is fixed and all http:// URLs are 
permanently redirected to their https:// exact equivalents. For MSIE 
this only works on POST.

307 - Portals doing policy agreements and splash pages. They require at 
minimum an arbitrary page of content to be visible to the user 
regardless of whether the request first made was a GET, CONNECT, POST 
etc. 307 seems to fit best until the 428 starts working on all requests. 
Preserving the method is important here.

3 months ago when I last saw this needed only Firefox and Chrome were 
doing 307 right. This is the first I've seen with MSIE on the good list 
there.

> That doesn't work, as given a new method name, you don't know whether

Thats one of the things the new drafts require them to indicate now, 
with unknowns treated as non-idempotent by default. yes?

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2011 13:26:48 +0200

> permanently redirected to their https:// exact equivalents. For MSIE

As far as I can tell, IE changes the method *only* for POST; whereas the 
other UAs change it for all methods. For this use case, the IE behavior 
seems to be strictly better, no?

> doing 307 right. This is the first I've seen with MSIE on the good list

We've tested this several times over the last years (for XHR), and all 
but Safari seemed to do the right thing here.

BTW: what is 428?

> with unknowns treated as non-idempotent by default. yes?

That may be fine for prompting, but definitively not for the question of 
silently changing the method.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Jul 2011 13:32:47 +0200

>BTW: what is 428?

Per http://tools.ietf.org/html/draft-nottingham-http-portal-02 "Network
Authentication Required".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Yves Lafon <[email-masked]>
Date: Mon, 18 Jul 2011 11:00:25 -0400 (EDT)

> How are those different (besides not crashing Opera, of course)?

Well, in XHR Safari rewrite all 307 methods to GET (from your report), not 
if done directly (POST -> 307 -> POST)
In Opera, you report that the method is preserved on 303 (so POST -> 303 
-> POST), while it is transformed in a GET "directly".

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2011 17:18:28 +0200

On 2011-07-18 17:00, Yves Lafon wrote:
>>>> ? MSIE/9.0 (latest) - all 301, 302 methods preserved except POST
> Well, in XHR Safari rewrite all 307 methods to GET (from your report),
> not if done directly (POST -> 307 -> POST)

As far as I recall, Safari has different code paths, and the bug only 
applies to synchronous XHR (when does it get fixed? the bug report is 
almost three years old...).

> -> POST), while it is transformed in a GET "directly".

...but didn't you say:

"For Opera/11.50 POST -> 307, popup to chose to redirect while 
preserving the method."

Typo?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 18 Jul 2011 12:16:36 -0700

On Mon, Jul 18, 2011 at 8:18 AM, Julian Reschke <[email-masked]> wrote:
> applies to synchronous XHR (when does it get fixed? the bug report is almost
> three years old...).

Bug number?

Adam

> "For Opera/11.50 POST -> 307, popup to chose to redirect while preserving
> the method."
>
> Typo?
>
> Best regards, Julian
>
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2011 21:27:51 +0200

>> applies to synchronous XHR (when does it get fixed? the bug report is almost

<https://bugs.webkit.org/show_bug.cgi?id=22532>

(raised by you, btw)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2011 09:54:53 +1000

Also reported to Apple by me a LONG time ago, don't have a ref handy.

---

From: Yves Lafon <[email-masked]>
Date: Tue, 19 Jul 2011 02:58:50 -0400 (EDT)

On Mon, 18 Jul 2011, Julian Reschke wrote:

> "For Opera/11.50 POST -> 307, popup to chose to redirect while preserving the 
> method."

This is the popup I have for a 307:
<<<
The server wants to redirect your form.

Press [Yes] to rePOST the form to the new destination.

Press [No] to GET the new destination without resending the form.

Press [Cancel] if you do not wish to continue.

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jul 2011 09:15:14 +0200

> Press [Cancel] if you do not wish to continue.

Oh - clearly a bug. Is this already reported?

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 19 Jul 2011 10:11:47 +0200

> Oh - clearly a bug. Is this already reported?

How is that a bug exactly? We have an open bug on removing this dialog  
though, asking the user makes little sense.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jul 2011 09:27:28 +0100

On 2011-07-19 09:11, Anne van Kesteren wrote:
> On Tue, 19 Jul 2011 09:15:14 +0200, Julian Reschke
> <[email-masked]> wrote:

The bug is that it offers to do a GET. Why would you ever want that?

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 19 Jul 2011 10:34:02 +0200

> The bug is that it offers to do a GET. Why would you ever want that?

I thought Roy said in some other thread that clients could do whatever  
they want? Anyway, this is going away.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jul 2011 09:40:10 +0100

On 2011-07-19 09:34, Anne van Kesteren wrote:
> On Tue, 19 Jul 2011 10:27:28 +0200, Julian Reschke

Clients in theory can do what they want, but it's very strange that one 
of the options is for a thing that seems to be the wrong thing all the time.

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Thu, 21 Jul 2011 08:30:01 -0400 (EDT)

> Also reported to Apple by me a LONG time ago, don't have a ref handy.

Testing on http://www.mnot.net/javascript/xmlhttprequest/ using the latest 
Safari (5.1, (6534.50))

307 Temporary Redirect, POST: success
307 Temporary Redirect, GET: success
307 Temporary Redirect, HEAD: fail (Redirected using , expected HEAD)
307 Temporary Redirect, PUT: success
307 Temporary Redirect, DELETE: success

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jul 2011 15:04:38 +0200

On 2011-07-21 14:30, Yves Lafon wrote:
> Testing on http://www.mnot.net/javascript/xmlhttprequest/ using the
> latest Safari (5.1, (6534.50))
>

Indeed!