Submitting forms with cross origin targets doesn't work.
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | fixed |
People
(Reporter: farre, Assigned: farre)
References
Details
Attachments
(3 files)
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
When this is fixed, the test for bug 1590762 should start working for fission.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
After much debugging I found out the difference that causes this to happen. If the body being sentin the request is "large enough" we will switch to sending a different nsIInputStream
across IPC[1]. Exactly what goes wrong after this I'm still not sure of, but one thing that becomes different as well is the resulting Http request. It looks like it has a limit at a Content-Length
of 1024*1024. Below that we get a request like:
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp http request [
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp POST http://mochi.test:8888/tests/docshell/test/mochitest/form_submit.sjs HTTP/1.1
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Host: mochi.test:8888
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Accept-Language: en-US,en;q=0.5
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Accept-Encoding: gzip, deflate
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Content-Type: application/x-www-form-urlencoded
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Content-Length: 1048481
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Origin: http://mochi.test:8888
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Connection: keep-alive
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Referer: http://mochi.test:8888/tests/docshell/test/mochitest/test_bug1645781.html
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp Upgrade-Insecure-Requests: 1
0:06.93 GECKO(42781) [Parent 42781: Main Thread]: E/nsHttp ]
and above:
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp http request [
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp POST http://mochi.test:8888/tests/docshell/test/mochitest/form_submit.sjs HTTP/1.1
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Host: mochi.test:8888
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Accept-Language: en-US,en;q=0.5
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Accept-Encoding: gzip, deflate
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Origin: http://mochi.test:8888
0:06.88 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Connection: keep-alive
0:06.89 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Referer: http://mochi.test:8888/tests/docshell/test/mochitest/test_bug1645781.html
0:06.89 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp Upgrade-Insecure-Requests: 1
0:06.89 GECKO(43440) [Parent 43440: Main Thread]: E/nsHttp ]
Notice the missing Content-Type
and Content-Length
headers in the request.
[1] https://searchfox.org/mozilla-central/source/ipc/glue/InputStreamUtils.cpp#283-303
Comment 4•4 years ago
|
||
I debugged this issue a bit. What I see is that:
- the content process A submits some data. This is a nsMIMEInputStream + a long long string inputStream. This stream is stored into a nsDocShellLoadState and it's sent to the parent process.
- The parent process receives a nsDocShellLoadState containing a nsMIMEInputStream + a pipe stream. The pipe is generated because the string inputStream has more than 1mb of data.
- the parent process sends the nsDocShellLoadState to content process B. At that point, nsMIMEInputStream is not serializable and it's sent as a pipe stream. Because of this extra pipe, the MIMEInputStream headers are gone. Also the stream size is gone. Process B, in order to know the amount of data to send, must read the whole stream...
There are different approaches to fix this issue, but I would point out that there are no reasons to send the stream so often around. Why process B needs to receive the whole data? In particular, because process B will send the same data back to the parent process. This means that we end up copying the same data 3 times.
What I suggest is to use IPCBlobInputStream. In this way, when the parent process sends the stream to the process B, it sends just an ID. Process B will receive a IPCBlobInputStream. No data copied.
When process B sends the stream back to the parent process, the parent process retrieves the "original" MIME InputStream from IPCBlobInputStreamStorage using the ID.
I wrote a prototype. It makes the test to pass but there is a bit of cleanup to do.
My patch does the following:
- it stores the stream size into a InputStreamLengthWrapper. This means that it's always possible to extract the size from the stream at any time without reading, even if, during the serialization, it's converted into a pipe.
- use IPCBlobInputStream in nsDocShellLoadState.
Comment 5•4 years ago
|
||
My patch depends on bug 1646933.
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
nsMIMEInputStream was conditionally serializable depending on the
wrapped stream. In general when a stream needs to be sent over IPC, if
it isn't serializable we send it using
InputStreamHelper::SerializeInputStreamAsPipe. There is no reason to
not branch on the wrapped stream when serializing nsMIMEInputStream
and use that, instead of sending the nsMIMEInputStream itself over a
pipe.
Depends on D79672
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f7ed7f9dc286 Part 1: Test that form submit works with fission. r=baku https://hg.mozilla.org/integration/autoland/rev/9df2d1f5a85d Part 2: Make nsMIMEInputStream always be serializable. r=baku,necko-reviewers
Comment 8•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f7ed7f9dc286
https://hg.mozilla.org/mozilla-central/rev/9df2d1f5a85d
Updated•4 years ago
|
Updated•1 year ago
|
Description
•