Note we add mClient->CacheClientSuspend() so the network state of the element
is changed to IDLE because we have no channel to fetch data initially.
MozReview-Commit-ID: DgJbMxvJBzH
--HG--
extra : rebase_source : 69a3ef35d4b5faaaa645fabe02246d49aebce22e
extra : source : 61ec40ce378a444ec0f74d474c28b6a9db3aa830
This is required by P2 where we want to notify the 'suspend' event for a cloned
resource whose mChannel is initially null.
MozReview-Commit-ID: 3znDl2TqlqK
--HG--
extra : rebase_source : 71c3d6dc2052566b6bfb0879ce56b804312c5a37
extra : source : e6b7cb7937c80420ad2725c5a77143c7a071150f
This adds a test where we have a ServiceWorker return 2 different types
of streams that Firefox recognizes as downloads which are handled by
diversion of the channel to the parent. The diverted downloads are
then cancelled and we verify that cancellation actually results in the
underlying connections being closed and/or the ServiceWorker notified.
Our 2 types of streams are:
1. A pass-through stream that is incrementally delivered through use of
an .sjs file that delivers data using setInterval.
2. A SW-authored ReadableStream (which is not enabled by default, so we
set a pref.)
Determining when the .sjs's stream is canceled is accomplished by
opening a second "monitor" connection that only completes when the
streaming connection is closed.
In all cases we differentiate between cancelation and timeouts firing.
--HG--
extra : rebase_source : bee2d8ae5dedfb88c1bb8fa5cf452014d74afaed
Currently, FetchStreamReader never signals to the JS stream code that
the reader has been closed. This means that when a ServiceWorker
passes a ReadableStream to respondWith and the HTTP Channel gets
canceled, the JS code will keep generating the stream without ever
realizing the data's not going anywhere. It's necessary to cancel
the reader. Or do something like that, this seems to work!
--HG--
extra : rebase_source : 559af90ba766ebd4deb5d99b6696cd2207215f9f
In the scenario where a ServiceWorker returns a pass-through fetch via
`evt.respondWith(fetch("underlying"))`, in order for the "underlying"
HTTP channel to be canceled when the outer HTTP channel is canceled,
FetchDriver's OnDataAvailable method needs to return an error when
the output pipe experiences an error.
Unfortunately, the contract for ReadSegments is effectively that it
returns NS_OK regardless of what the rv of the write handler returned,
so relying on the returned rv is insufficient. And because various
Write*() methods will all fast-path to returning NS_OK if a count of 0
is passed, it's necessary to infer a closed/broken pipe by noticing
that we tried to write more than 0 bytes of data but 0 bytes were
written. (This is safe because the pipe we write into was created
by FetchDriver::OnStartRequest which explicitly creates an infinite
pipe, so it's not possible for the write to fail due to lack of space
in the pipe.)
--HG--
extra : rebase_source : 788dab679298841fc03bb054458b6f8cc4a0a8d9
Jon Coppeard
Andrea Marchesini
Dorel Luca
Stone Shih
Narcis Beleuzu
Brindusan Cristian
Adrian Wielgosik
Brad Werth
Mats Palmgren
JW Wang
Andreea Pavel
Andrew Sutherland
Ben Kelly
Sebastian Hengst
Jeff Gilbert