This flag was previously being set for every page reload.
Only setting it for force-reload makes it so that we don't needlessly refresh
DNS cache entries and improves page load performance.
Differential Revision: https://phabricator.services.mozilla.com/D208141
Content processes will now always retarget delivery of OnDataAvailable for Http
channels off the main thread. Consumers that were previously redirecting
off-main thread are not affected and their retargeting will stick, but any
Httpchannel that was not retargeted off the main thread will be retargeted to
the nsIStreamTransportService.
If the listener for nsHTTPCompressConv cannot be called off the main thread (ie
the call to nsIRetargetableRequest::CheckListenerChain would fail),
nsHTTPCompressConv will be called off main thread but dispatch its decoded data
back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D191377
Content processes will now always retarget delivery of OnDataAvailable for Http
channels off the main thread. Consumers that were previously redirecting
off-main thread are not affected and their retargeting will stick, but any
Httpchannel that was not retargeted off the main thread will be retargeted to
the nsIStreamTransportService.
If the listener for nsHTTPCompressConv cannot be called off the main thread (ie
the call to nsIRetargetableRequest::CheckListenerChain would fail),
nsHTTPCompressConv will be called off main thread but dispatch its decoded data
back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D191377
This notification would be sent by HttpChannelChild before
calling onStopRequest for a channel.
This patch also updates some comments regarding the on stop topic
which referenced the non-existent http-on-stop-connect
Differential Revision: https://phabricator.services.mozilla.com/D204482
While the http-on-before-connect event is dispatched before
the DNS resolution had completed, it was apparent that the channel also
set multiple headers and flags during nsHttpChannel::SetupTransaction
when the transaction was actually dispatched. This meant that
any JS consumers that were looking to suspend or cancel the channel
based on various headers would not have the full set of headers available
when receiving the http-on-before-connect notification.
This patch adds a new http-on-dispatching-transaction notification that
is emitted just before the transaction is dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D199333
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
The current serverCertificateHashes implementation does not follow the
WebTransport specification, that introduced serverCertificateHashes
as a tool to replace certificate chain verification.
Instead it introduced the hashes as an additional check.
This patch moves the check to the Http3Session object and modifies
the connection manager' hashes to prevent crossSite certificate
poisoning. It is - as the WebTransport Implementation in Firefox -
currently limited to http3 only.
However, since the hashes live on the ConnectionEntries,
it should be possible to extend this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D197857
The current serverCertificateHashes implementation does not follow the
WebTransport specification, that introduced serverCertificateHashes
as a tool to replace certificate chain verification.
Instead it introduced the hashes as an additional check.
This patch moves the check to the Http3Session object and modifies
the connection manager' hashes to prevent crossSite certificate
poisoning. It is - as the WebTransport Implementation in Firefox -
currently limited to http3 only.
However, since the hashes live on the ConnectionEntries,
it should be possible to extend this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D197857
- Remove CACHE_SERVICE_LOCK_WAIT_* as they are no longer referenced
- Remove HTTP_OFFLINE_CACHE_DOCUMENT_LOAD as it's no longer useful - appcache got removed
Differential Revision: https://phabricator.services.mozilla.com/D201067
While the http-on-before-connect event is dispatched before
the DNS resolution had completed, it was apparent that the channel also
set multiple headers and flags during nsHttpChannel::SetupTransaction
when the transaction was actually dispatched. This meant that
any JS consumers that were looking to suspend or cancel the channel
based on various headers would not have the full set of headers available
when receiving the http-on-before-connect notification.
This patch adds a new http-on-dispatching-transaction notification that
is emitted just before the transaction is dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D199333
Create a new glean probe for http response version so that we can collect on android, and also we'll collect on release.
Differential Revision: https://phabricator.services.mozilla.com/D199764
While debugging 1871533 we found out that the new transactions were not dispatched as the pending queue had 6 active connections.
The connections (although were marked as DONT reuse) were not cleared from the pending queue because sticky transactions were still holding their references.
Differential Revision: https://phabricator.services.mozilla.com/D199863
Adding a new HeaderVariety called eVarietyRequestEnforceDefault. It
allows setting request header value as default even even if the header
exists.
We need this to setting default header value without changing the order
of the header.
Differential Revision: https://phabricator.services.mozilla.com/D199991
The userAgent header can be modified in several ways, such as using the
header field to set a custom userAgent header for a fetch request. We
want to preserve the custom header, so we shouldn't recalculate the
userAgent header if it's been overridden after the channel was created.
Otherwise, the custom header won't work.
Differential Revision: https://phabricator.services.mozilla.com/D197655
The userAgent was decided when the channel was created, but the channel
hasn't known about whether it should exempt fingerprinting protection at
the moment. To properly set the userAgent, we need to update the
userAgent header once we know the AntiTracking info.
Differential Revision: https://phabricator.services.mozilla.com/D196953
The userAgent header can be modified in several ways, such as using the
header field to set a custom userAgent header for a fetch request. We
want to preserve the custom header, so we shouldn't recalculate the
userAgent header if it's been overridden after the channel was created.
Otherwise, the custom header won't work.
Differential Revision: https://phabricator.services.mozilla.com/D197655
