Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#160 closed design (fixed)

Redirects and non-GET methods

Reported by: mnot@… Owned by: mnot@…
Priority: urgent Milestone: 17
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:

Description (last modified by 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.

Attachments (2)

160.2.diff (7.1 KB) - added by julian.reschke@… 6 years ago.
(work in progress)
160.diff (7.1 KB) - added by julian.reschke@… 6 years ago.
(work in progress)

Download all attachments as: .zip

Change History (34)

comment:1 Changed 8 years ago by julian.reschke@…

  • Priority set to normal

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

comment:2 Changed 8 years ago by mnot@…

  • Priority changed from normal to urgent

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by fielding@…

... as a SHOULD level requirement.

comment:5 Changed 8 years ago by fielding@…

... except for HEAD would remain HEAD.

comment:6 Changed 8 years ago by mnot@…

Covered in Stockholm; needs more discussion on-list.

comment:7 Changed 7 years ago by mnot@…

  • Description modified (diff)

comment:8 follow-ups: Changed 7 years ago by 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.

comment:9 in reply to: ↑ 8 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by julian.reschke@…

comment:11 Changed 7 years ago by julian.reschke@…

comment:12 Changed 7 years ago by julian.reschke@…

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

comment:13 Changed 7 years ago by julian.reschke@…

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

comment:14 Changed 7 years ago by julian.reschke@…

comment:15 Changed 7 years ago by julian.reschke@…

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

comment:16 Changed 7 years ago by julian.reschke@…

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

comment:17 Changed 6 years ago by mnot@…

  • Owner set to mnot@…

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

comment:18 Changed 6 years ago by 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

comment:19 follow-up: Changed 6 years ago by 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

comment:20 in reply to: ↑ 8 Changed 6 years ago by 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.

comment:21 in reply to: ↑ 19 Changed 6 years ago by 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>

Last edited 6 years ago by julian.reschke@… (previous) (diff)

comment:22 follow-up: Changed 6 years ago by 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.

comment:23 Changed 6 years ago by 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.

comment:24 in reply to: ↑ 22 Changed 6 years ago by 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).

comment:25 Changed 6 years ago by julian.reschke@…

Changed 6 years ago by julian.reschke@…

(work in progress)

Changed 6 years ago by julian.reschke@…

(work in progress)

comment:27 follow-up: Changed 6 years ago by julian.reschke@…

  • Milestone changed from unassigned to 17
  • Resolution set to incorporated
  • Status changed from new to closed

See #1428

comment:28 in reply to: ↑ 27 Changed 6 years ago by julian.reschke@…

Replying to julian.reschke@…:

See #1428

[1428], actually.

comment:29 Changed 6 years ago by 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.

comment:30 Changed 5 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:31 Changed 5 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:32 Changed 5 years ago by 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)

Note: See TracTickets for help on using tickets.