Requests may be canceled before AsyncOpen is even called. In that case
we don't want to add START markers, and we don't want to add CANCEL
markers for these requests that didn't even start yet.
Depends on D123255
Differential Revision: https://phabricator.services.mozilla.com/D123256
This patch tries to record the fetch event dispatching time, the response's synthesizing time, and interception resetting time.
Fetch event dispatching time is the time duration between interception starts, which is the time point of InterceptedHttpChannel::AsyncOpenInternal(), and the fetch handler starts. It includes the InterceptedHttpChannel setup time, ServiceWorker launch time, FetchEventOp propagation through IPC, a FetchEvent creation, initialization, and dispatching/scheduling on worker scope.
Response synthesizing time is the time duration between the fetch handler finishes, which is the resolving/rejecting promise of respondWith(), to the finish of pumping the synthesized response to InterceptedHttpChannel, which is the time point of calling InterceptedHttpChannel::OnStopRequest(). It includes the response propagation through IPC, response header and body synthesis, and pumping synthesized response to the channel.
Interception resetting time is the time duration between the fetch handler finishes and redirecting InterceptedHttpChannel to a normal HTTP channel.
Since the fetch handler is executed on the process where the service worker spawned, the timestamps related to the fetch handler need to be get on that process. So this patch adds the FetchHandlerStart and FetchHandlerFinish on IPCFetchEventRespondWithResult related types to propagate the timestamps to the parent process.
Depends on D118398
Differential Revision: https://phabricator.services.mozilla.com/D118399
Class InterceptionTimeStamps is introduced to help to record fetch-related timing. It is a private class of InterceptedHttpChannel since should use it in InterceptedHttpChannel only.
We are probably not only interested in the resource type, navigation or subresource, but also the final status of fetching, Synthesized, Reset, Canceled, or Redirected. So the fetch's final status also be appended on the sub-key of telemetry.
Depends on D118397
Differential Revision: https://phabricator.services.mozilla.com/D118398
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
When `respondWith` isn't called, then we run the "reset interception"
steps, which sets up a new channel and does an internal redirect. We
need a profiler network marker with the "REDIRECT" status to properly
track this.
Differential Revision: https://phabricator.services.mozilla.com/D112216
This is simplifying how we pass the URI, and this is abstracting how we
pass the size.
In general the goal is to use properties and methods from
HttpBaseChannel, so that maybe in the future we could abstract marker
handling to that parent class.
Differential Revision: https://phabricator.services.mozilla.com/D112212
Storing the charset on cache entries makes the code path uselessly different
when loading from cache relative to uncached loads. Also, for future
telemetry purposes, caching the charset obscures its original source.
Differential Revision: https://phabricator.services.mozilla.com/D101570
