Bug 201950 – REGRESSION (r238252): HTTP POST is losing application/x-www-form-urlencoded body if there's a redirect to different host

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Julio Monteiro]

SUMMARY:

Issuing HTTP POST with application/x-www-form-urlencoded query component (aka "form data", "request data" or "body data") and being redirected to a different host is causing the query component to be lost/removed/ignored.

REPRODUCTION STEPS:

1. Issue a HTTP POST with application/x-www-form-urlencoded query component to a page
2. In the page receiving the HTTP POST with application/x-www-form-urlencoded query component, return status HTTP 307 (temp redirect) to another page in a different domain or subdomain.
3. In this different domain or subdomain, receive the HTTP POST and print the application/x-www-form-urlencoded query component received.

EXPECTED RESULT: Correctly receive the application/x-www-form-urlencoded query component in the final page.

ACTUAL RESULT: application/x-www-form-urlencoded query component isn't received, although the request is kept as HTTP POST.

PROOF OF CONCEPT:
1. Open https://redirection-experiment.herokuapp.com on Safari/WebKit
2. It will redirect you to a different domain (redirection-experiment-landing.herokuapp.com)
3. You'll notice that the application/x-www-form-urlencoded query component `content=something` isn't sent to the different host redirection-experiment-landing.herokuapp.com in the end.

Source code can be found at https://github.com/jmonteiro/redirection-experiment/blob/master/app.rb (for https://redirection-experiment.herokuapp.com) and https://github.com/jmonteiro/redirection-experiment-landing/blob/master/app.rb (for https://redirection-experiment-landing.herokuapp.com).

Repeat the same process on any other browsers (such as Firefox, Chrome, etc) and this issue will not happen.

NOTES:
 * Confirmed on Safari 12.1.2 (14607.3.9) for macOS, Safari for iOS (iOS v 12.4.1), and Webkit build r250050. Tested on other browsers (latests from Chrome for macOS and Windows, Firefox for macOS and Windows, Brave for macOS and Windows, Edge and Internet Explorer) and they are not affected by this issue.
 * This appears only to happen when the host changes. If the same steps are taken in the same host, the issue won't happen.
 * Documentation on MDN specifies that for the 307 redirection, "The method and the body of the original request are reused to perform the redirected request." (source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307)
 * Looking at the RFC 7231 Section 6.4.7 regarding 307 status, there's no mention about the application/x-www-form-urlencoded query component being either kept or ignored, so I'm not sure if this is just a de-facto standard among browsers, or if this is documented somewhere. (source: https://tools.ietf.org/html/rfc7231#section-6.4.7)

[Radar WebKit Bug Importer]

<rdar://problem/55577782>

[Chris Dumez]

Even though I wasn't expecting it here, it seems we are process-swapping:
Source URL is https://redirection-experiment.herokuapp.com/ / Target URL is https://redirection-experiment-landing.herokuapp.com/landing / targetRegistrableDomain is redirection-experiment-landing.herokuapp.com

For some reason, redirection-experiment-landing.herokuapp.com is recognized as a registrable domain and not herokuapp.com. This seems to have found a bug in our process-swap on navigation code path.

[Chris Dumez]

(In reply to Chris Dumez from comment #2)
> Even though I wasn't expecting it here, it seems we are process-swapping:
> Source URL is https://redirection-experiment.herokuapp.com/ / Target URL is
> https://redirection-experiment-landing.herokuapp.com/landing /
> targetRegistrableDomain is redirection-experiment-landing.herokuapp.com
> 
> For some reason, redirection-experiment-landing.herokuapp.com is recognized
> as a registrable domain and not herokuapp.com. This seems to have found a
> bug in our process-swap on navigation code path.

We just checked with John and herokuapp.com is a public suffix so process-swap is expected here. So the good news is that we only have 1 bug.

[Chris Dumez]

Created attachment 382319 [details]
WIP Patch

Still needs a test but it works.

[Chris Dumez]

Created attachment 382320 [details]
WIP Patch

[Chris Dumez]

Created attachment 382322 [details]
Patch

[EWS Watchlist]

Comment on attachment 382322 [details]
Patch

Attachment 382322 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/13191755

New failing tests:
http/tests/misc/form-submit-file-cross-site-redirect.html

[EWS Watchlist]

Created attachment 382335 [details]
Archive of layout-test-results from ews210 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews210  Port: win-future  Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit

[Chris Dumez]

Committed r251786: <https://trac.webkit.org/changeset/251786>

[Chris Dumez]

(In reply to Julio Monteiro from comment #0)
> SUMMARY:
> 
> Issuing HTTP POST with application/x-www-form-urlencoded query component
> (aka "form data", "request data" or "body data") and being redirected to a
> different host is causing the query component to be lost/removed/ignored.
> 
> REPRODUCTION STEPS:
> 
> 1. Issue a HTTP POST with application/x-www-form-urlencoded query component
> to a page
> 2. In the page receiving the HTTP POST with
> application/x-www-form-urlencoded query component, return status HTTP 307
> (temp redirect) to another page in a different domain or subdomain.
> 3. In this different domain or subdomain, receive the HTTP POST and print
> the application/x-www-form-urlencoded query component received.
> 
> EXPECTED RESULT: Correctly receive the application/x-www-form-urlencoded
> query component in the final page.
> 
> ACTUAL RESULT: application/x-www-form-urlencoded query component isn't
> received, although the request is kept as HTTP POST.
> 
> PROOF OF CONCEPT:
> 1. Open https://redirection-experiment.herokuapp.com on Safari/WebKit
> 2. It will redirect you to a different domain
> (redirection-experiment-landing.herokuapp.com)
> 3. You'll notice that the application/x-www-form-urlencoded query component
> `content=something` isn't sent to the different host
> redirection-experiment-landing.herokuapp.com in the end.
> 
> Source code can be found at
> https://github.com/jmonteiro/redirection-experiment/blob/master/app.rb (for
> https://redirection-experiment.herokuapp.com) and
> https://github.com/jmonteiro/redirection-experiment-landing/blob/master/app.
> rb (for https://redirection-experiment-landing.herokuapp.com).
> 
> Repeat the same process on any other browsers (such as Firefox, Chrome, etc)
> and this issue will not happen.
> 
> NOTES:
>  * Confirmed on Safari 12.1.2 (14607.3.9) for macOS, Safari for iOS (iOS v
> 12.4.1), and Webkit build r250050. Tested on other browsers (latests from
> Chrome for macOS and Windows, Firefox for macOS and Windows, Brave for macOS
> and Windows, Edge and Internet Explorer) and they are not affected by this
> issue.
>  * This appears only to happen when the host changes. If the same steps are
> taken in the same host, the issue won't happen.
>  * Documentation on MDN specifies that for the 307 redirection, "The method
> and the body of the original request are reused to perform the redirected
> request." (source:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307)
>  * Looking at the RFC 7231 Section 6.4.7 regarding 307 status, there's no
> mention about the application/x-www-form-urlencoded query component being
> either kept or ignored, so I'm not sure if this is just a de-facto standard
> among browsers, or if this is documented somewhere. (source:
> https://tools.ietf.org/html/rfc7231#section-6.4.7)

Thank you for the bug report and the very nice reproduction case Julio, this was very helpful.