* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #160 (closed design: fixed)

Opened 5 years ago

Last modified 3 years ago

Redirects and non-GET methods

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: urgent Milestone: 17
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/op.ume0smlivqd7e2@killashandra.oslo.opera.com

Description (last modified by mnot@pobox.com) (diff)

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

160.2.diff (7.1 KB) - added by julian.reschke@gmx.de 3 years ago.
(work in progress)
160.diff (7.1 KB) - added by julian.reschke@gmx.de 3 years ago.
(work in progress)

Change History

comment:1 Changed 5 years ago by julian.reschke@gmx.de

  • 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 5 years ago by mnot@pobox.com

  • Priority changed from normal to urgent

comment:3 Changed 5 years ago by fielding@gbiv.com

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 5 years ago by fielding@gbiv.com

... as a SHOULD level requirement.

comment:5 Changed 5 years ago by fielding@gbiv.com

... except for HEAD would remain HEAD.

comment:6 Changed 5 years ago by mnot@pobox.com

Covered in Stockholm; needs more discussion on-list.

comment:7 Changed 4 years ago by mnot@pobox.com

  • Description modified (diff)

comment:8 follow-ups: ↓ 9 ↓ 20 Changed 4 years ago by julian.reschke@gmx.de

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 4 years ago by julian.reschke@gmx.de

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 4 years ago by julian.reschke@gmx.de

comment:11 Changed 4 years ago by julian.reschke@gmx.de

comment:12 Changed 4 years ago by julian.reschke@gmx.de

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

comment:13 Changed 4 years ago by julian.reschke@gmx.de

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

comment:14 Changed 4 years ago by julian.reschke@gmx.de

comment:15 Changed 4 years ago by julian.reschke@gmx.de

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

comment:16 Changed 4 years ago by julian.reschke@gmx.de

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

comment:17 Changed 3 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com

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

comment:18 Changed 3 years ago by mnot@pobox.com

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 3 years ago by mnot@pobox.com

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 3 years ago by mnot@pobox.com

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 3 years ago by julian.reschke@gmx.de

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 3 years ago by julian.reschke@gmx.de (previous) (diff)

comment:22 follow-up: ↓ 24 Changed 3 years ago by bzbarsky@mit.edu

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 3 years ago by mnot@pobox.com

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 3 years ago by julian.reschke@gmx.de

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 3 years ago by julian.reschke@gmx.de

Changed 3 years ago by julian.reschke@gmx.de

(work in progress)

Changed 3 years ago by julian.reschke@gmx.de

(work in progress)

comment:27 follow-up: ↓ 28 Changed 3 years ago by julian.reschke@gmx.de

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

See #1428

comment:28 in reply to: ↑ 27 Changed 3 years ago by julian.reschke@gmx.de

Replying to julian.reschke@…:

See #1428

[1428], actually.

comment:29 Changed 3 years ago by fielding@gbiv.com

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 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:31 Changed 3 years ago by mnot@pobox.com

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

comment:32 Changed 3 years ago by julian.reschke@gmx.de

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.