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
Using nsMainThreadPtrHandle to hold the nsICacheInfoChannel in the
InternalResponse.
--HG--
extra : histedit_source : 125f31c63fce1cbd9995d29688e7795efad3a417
Setting the InternalResponse's mCacheInfoChannel while needed, to avoid
keeping unnecessary nsICacheInfoChannel alive.
--HG--
extra : histedit_source : 39f9339b69db52b0278495d5247bc99ffd1d8f79
Create a new class AlternativeDataStreamListener for alternative data and
main data overlap loading.
AlternativeDataStreamListener coorperates with FetchDriver to handle
following situations
1. There is no preferred alternative data type in InternalRequest
Directly using FetchDriver to listen on the opened channel
2. If preferred alternative data type exists in InternalRequest, but no
saved data in cache.
AlternativeDataStreamListener is constructed to listen on the channel,
but its status would be set as FALLBACK and redirect callbacks to
FetchDriver.
3. If preferred alternative data type exists in InternalRequest, and the
data also exists in the cache.
AlternativeDataStreamListener is constructed to listen on the channel
for loading the alternative data. And also open a channel listened by
FetchDriver for loading the main data when AlternativeDataStreamListener::
OnStartRequest is called.
If the cacheEntryId is different between main data channel and
alternative data channel, we will cancel the alternative data loading.
These were detected by the script used to generate part 2.
MozReview-Commit-ID: VMcT154f6f
--HG--
extra : rebase_source : 2f5fc8a314302fcacac840a8dbe0ff874d518e51
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: F750v6NN81s
--HG--
extra : rebase_source : 714dd78df0f4c33e23e5b117615bd8fd561674c5
extra : source : 742bda9e6b1ddaf34d09894204ad18ce798b79b7
