Redirects and non-GET methods

[mnot@…]

Despite the advice in RFC2616, many (most?) client implementations will convert a non-GET request to GET upon a 301 or 302 redirect.

See also #238 regarding automatic redirects.

[julian.reschke@…]

​http://www.mnot.net/javascript/xmlhttprequest/ has tests related to rewriting the methods names when called through XmlHttpRequest?.

[fielding@…]

IIRC, editors' plan is make 301 and 302 change to GET method on redirect and explain the history. 307 would indicate permanence (if any) via expires and cache-control.

[fielding@…]

... as a SHOULD level requirement.

[fielding@…]

... except for HEAD would remain HEAD.

[mnot@…]

Covered in Stockholm; needs more discussion on-list.

[julian.reschke@…]

Note that IE does *only* rewrite POST, other method aren't rewritten (see Mark's tests at ​http://www.mnot.net/javascript/xmlhttprequest/).

From that point of view, I'd recommend to restrict the change to POST, and also leave the old behavior compliant.

[julian.reschke@…]

Replying to julian.reschke@…:

Note that IE does *only* rewrite POST, other method aren't rewritten (see Mark's tests at ​http://www.mnot.net/javascript/xmlhttprequest/). ...

I also just checked CURL, and contrary to what some docs say, it appears to preserve the method name on 301.

[julian.reschke@…]

Related Konqueror bug: ​http://bugs.kde.org/show_bug.cgi?id=251456

[julian.reschke@…]

Related Mozilla Bug: ​https://bugzilla.mozilla.org/show_bug.cgi?id=598304

[julian.reschke@…]

Webkit bug (redirected HEAD): ​https://bugs.webkit.org/show_bug.cgi?id=42663

[julian.reschke@…]

Webkit bug (redirect for methods =! POST): ​https://bugs.webkit.org/show_bug.cgi?id=46183

[julian.reschke@…]

Chromium bug (redirected HEAD): ​http://code.google.com/p/chromium/issues/detail?id=49684

[julian.reschke@…]

Chromium bug (redirect for methods =! POST): ​http://code.google.com/p/chromium/issues/detail?id=56373

[julian.reschke@…]

Opera bug (redirect for methods =! POST): DSK-314160

[mnot@…]

TODO: Mark to write test script, work with UA vendors and summarise results

[mnot@…]

Using ​http://www.mnot.net/javascript/xmlhttprequest/ -

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

[mnot@…]

Using ​http://www.mnot.net/javascript/xmlhttprequest/ -

• 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

[mnot@…]

Replying to julian.reschke@…:

From that point of view, I'd recommend to restrict the change to POST, and also leave the old behavior compliant.

That seems reasonable.

[julian.reschke@…]

Replying to mnot@…:

Using ​http://www.mnot.net/javascript/xmlhttprequest/ -

• Safari/533.21.1 - all 301, 302, 307 rewritten to GET; 303 methods are preserved

My understanding is that this "only" applies to synchronous XHR requests; see <​https://bugs.webkit.org/show_bug.cgi?id=22532>

[bzbarsky@…]

Mark, as far as I know Firefox does not preserve the method on 303 requests; we only do it on 307 requests. Furthermore, RFC 2616 clearly says that the method should be converted to GET when following a 303, so it would somewhat surprise me if every single browser chose to violate that. Could you please double-check your data?

Two other question:

1) How does preserving the request method correlate with also preserving the

request entity body in those browsers? In Firefox the two are tied to each other, but it's not clear whether this is the case across the board.

2) Is the IE behavior consistent for XMLHttpRequest and requests issued via

ActiveX plug-in APIs? Either one would not surprise me, given historical IE behavior where multiple libraries that do similar things can be involved.

[mnot@…]

Sorry Boris, my mistake -- all of the browsers handle 303 correctly. I meant 'changed to GET' in those cases (i.e., passed).

WRT your questions -- I'll get back to you.

[julian.reschke@…]

Replying to bzbarsky@…:

1) How does preserving the request method correlate with also preserving the

request entity body in those browsers? In Firefox the two are tied to each other, but it's not clear whether this is the case across the board.

I think this should be the case across the board. If the original request had a payload, and the client decides to submit it to a different URI, the payload needs to be sent as well (as "most" header fields).

2) Is the IE behavior consistent for XMLHttpRequest and requests issued via

ActiveX plug-in APIs? Either one would not surprise me, given historical IE behavior where multiple libraries that do similar things can be involved.

Not sure. I recall that MSXML's XHR had a bug where it would automatically follow a 301/302 upon PROPFIND but drop the request body while sending C-L, causing the request to have to time-out (there you have it: that component does not rewrite PROPFIND).

[julian.reschke@…]

Proposed patch for Firefox: see <​https://bugzilla.mozilla.org/show_bug.cgi?id=598304#c15>

[julian.reschke@…]

See ​http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx

[julian.reschke@…]

(work in progress)

[julian.reschke@…]

(work in progress)

[julian.reschke@…]

See #1428

[julian.reschke@…]

Replying to julian.reschke@…:

See #1428

[1428], actually.

[fielding@…]

BTW, I explained the history of this back in 1997:

​http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0611.html

such fun.

[julian.reschke@…]

Chrome 17 is released and does not rewrite the method for 301/302 anymore except for HEAD. (IE has been doing this forever)