Handle multipart/x-mixed-replace responses in the parent process
Categories
(Core :: Networking, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: mattwoodrow, Assigned: mattwoodrow)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(9 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
We currently do multipart/x-mixed-replace handling in the content process, which makes it impossible to handle downloadable parts entirely in the parent process (as we'd like to do in bug 1574372).
If we run this in the parent process, we can make a per-part decision on where the direct the content to, and only send content to be displayed down into the content process.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D55215
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D55216
Assignee | ||
Comment 4•5 years ago
|
||
Depends on D55217
Assignee | ||
Comment 5•5 years ago
|
||
This also removes OnStartRequestSent from PHttpBackgroundChannel, since there should never be any messages sent earlier on this channel, so we can just assume the waiting state initially.
Depends on D55218
Assignee | ||
Comment 6•5 years ago
|
||
We can't always know when sending a part if it'll be the last one (either because the channel is later cancelled, or because the response just sends the end boundary without warning). This was initially reported in bug 339610.
Depends on D55219
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D55220
Assignee | ||
Comment 8•5 years ago
|
||
We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.
When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.
This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).
Depends on D55221
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D55222
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9300f56262d4
https://hg.mozilla.org/mozilla-central/rev/5caa332c7edb
https://hg.mozilla.org/mozilla-central/rev/e07c2e552828
https://hg.mozilla.org/mozilla-central/rev/1f8f8d00df76
https://hg.mozilla.org/mozilla-central/rev/a2ec935602ab
https://hg.mozilla.org/mozilla-central/rev/5b4c042c0d18
https://hg.mozilla.org/mozilla-central/rev/2d16a3cedb87
https://hg.mozilla.org/mozilla-central/rev/e4dea7d4d633
https://hg.mozilla.org/mozilla-central/rev/1e479194244a
Description
•