#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@…)
Attachments (2)
Change History (34)
comment:1 Changed 14 years ago by julian.reschke@…
- Priority set to normal
comment:2 Changed 14 years ago by mnot@…
- Priority changed from normal to urgent
comment:3 Changed 14 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 14 years ago by fielding@…
... as a SHOULD level requirement.
comment:5 Changed 14 years ago by fielding@…
... except for HEAD would remain HEAD.
comment:6 Changed 13 years ago by mnot@…
Covered in Stockholm; needs more discussion on-list.
comment:7 Changed 13 years ago by mnot@…
- Description modified (diff)
comment:8 follow-ups: ↓ 9 ↓ 20 Changed 12 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 12 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 12 years ago by julian.reschke@…
Related Konqueror bug: http://bugs.kde.org/show_bug.cgi?id=251456
comment:11 Changed 12 years ago by julian.reschke@…
Related Mozilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=598304
comment:12 Changed 12 years ago by julian.reschke@…
Webkit bug (redirected HEAD): https://bugs.webkit.org/show_bug.cgi?id=42663
comment:13 Changed 12 years ago by julian.reschke@…
Webkit bug (redirect for methods =! POST): https://bugs.webkit.org/show_bug.cgi?id=46183
comment:14 Changed 12 years ago by julian.reschke@…
Chromium bug (redirected HEAD): http://code.google.com/p/chromium/issues/detail?id=49684
comment:15 Changed 12 years ago by julian.reschke@…
Chromium bug (redirect for methods =! POST): http://code.google.com/p/chromium/issues/detail?id=56373
comment:16 Changed 12 years ago by julian.reschke@…
Opera bug (redirect for methods =! POST): DSK-314160
comment:17 Changed 12 years ago by mnot@…
- Owner set to mnot@…
TODO: Mark to write test script, work with UA vendors and summarise results
comment:18 Changed 12 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: ↓ 21 Changed 12 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 12 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 12 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>
comment:22 follow-up: ↓ 24 Changed 12 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 12 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 12 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 12 years ago by julian.reschke@…
Proposed patch for Firefox: see <https://bugzilla.mozilla.org/show_bug.cgi?id=598304#c15>
comment:26 Changed 11 years ago by julian.reschke@…
comment:27 follow-up: ↓ 28 Changed 11 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 11 years ago by julian.reschke@…
comment:29 Changed 11 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 11 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:31 Changed 11 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
comment:32 Changed 11 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)
http://www.mnot.net/javascript/xmlhttprequest/ has tests related to rewriting the methods names when called through XmlHttpRequest?.