CLOSED TREE
Backed out changeset 511af4b42efc (bug 1734132)
Backed out changeset 9516eb1214d8 (bug 1734132)
Backed out changeset 513d740d6477 (bug 1734132)
According to https://datatracker.ietf.org/doc/html/rfc7540#section-4.2
The size of a frame payload is limited by the maximum size that a
receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This
setting can have any value between 2^14 (16,384) and 2^24-1
(16,777,215) octets, inclusive.
Our previous clamping to 0x3fff prevented us from writing more than
16K bytes at a time for HTTP/2.
See bug 1596576 comment 61 and bug 1596576 comment 54.
This patch doesn't change the default value of the pref, it just allows
us to experiment with a larger chunk size.
Differential Revision: https://phabricator.services.mozilla.com/D130856
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
This patch:
1. adds two 'highValueHasSavedLogin' and 'highValueIsLoggedIn' permission
2. moves 'AddHighValuePermission' from HttpBaseChannel to ProcessIsolation
to support more high-value permission type.
Differential Revision: https://phabricator.services.mozilla.com/D127101
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
This patch:
1. adds two 'highValueHasSavedLogin' and 'highValueIsLoggedIn' permission
2. moves 'AddHighValuePermission' from HttpBaseChannel to ProcessIsolation
to support more high-value permission type.
Differential Revision: https://phabricator.services.mozilla.com/D127101
This patch:
1. adds two 'highValueHasSavedLogin' and 'highValueIsLoggedIn' permission
2. moves 'AddHighValuePermission' from HttpBaseChannel to ProcessIsolation
to support more high-value permission type.
Differential Revision: https://phabricator.services.mozilla.com/D127101
Currently, soft reload uses the `VALIDATE_ALWAYS` flag to not only
force revalidate the top level document, but also subresources.
This causes content to be refetched from the web even if there
are caches that are still valid and can be used.
Chrome already has such behaviour to not revalidate all resources.
Differential Revision: https://phabricator.services.mozilla.com/D122270
Make the following functions private because they are only used in nsHttpResponseHead.cpp for compiler optimization-
GetDateValue,GetAgeValue,GetMaxAgeValue,GetExpiresValue.
GetLastModifiedValue cannot be made private since it is being used in CachePushChecker.cpp and ParseDateHeader is already private.
Differential Revision: https://phabricator.services.mozilla.com/D129664
CLOSED TREE
Backed out changeset 309190b4a49d (bug 1732792)
Backed out changeset 600e6dfd7436 (bug 1732792)
Backed out changeset 834441a08cc0 (bug 1733481)
It seems that the serialization generated by inet_ntop_internal via
getnameinfo is sometimes wrong, returning `?` instead of serializing the
IP we pass in.
It's also inefficient to keep passing the serialization to and from rust
code - instead it's much easier to just pass a pointer to the NetAddr
union and build a proper SocketAddr instance on the rust side from
from the bytes instead of parsing the serialization
Differential Revision: https://phabricator.services.mozilla.com/D129489
It seems that the serialization generated by inet_ntop_internal via
getnameinfo is sometimes wrong, returning `?` instead of serializing the
IP we pass in.
It's also inefficient to keep passing the serialization to and from rust
code - instead it's much easier to just pass a pointer to the NetAddr
union and build a proper SocketAddr instance on the rust side from
from the bytes instead of parsing the serialization
Differential Revision: https://phabricator.services.mozilla.com/D129489
This is an appropriate error to set and it may cause transactions to be restarted if possible (e.g. no data has been received already and the method is safe).
Differential Revision: https://phabricator.services.mozilla.com/D127877
This patch introduces:
- a second nsICancelable out param in nsBaseChannel::BeginAsyncRead, which is meant to be non-null
when the subclass is unable to set the nsIRequest out param right away (e.g because there is
some async work needed before the subclass is able to get an nsIRequest instance).
The nsICancelable does only allow the channel to cancel the underlying request (and stream pump),
but it doesn't allow the channel to be suspended and resumed, but that was already the case
for the subclasses that were already not returning an nsIRequest instance (e.g. like the
ExtensionProtocolHandler was doing when it is asynchrously retriving a stream from the parent
process).
- require NotNull<nsCOMPtr<...>> in the SimpleChannel's BeginAsyncRead callback signature, to make harder
to overlook the requirement of returning an nsIRequest or nsICancelable.
- a diagnostic assertion (from SimpleChannel's BeginAsyncRead method) to more visible fail if we still end
up with neither an nsIRequest or nsICancelable result as SimpleChannel callback result.
- changes to ExtensionProtocolHandler, PageThumbProtocolHandler and nsAnnoProtocolHandler to adapt them
to the new nsBaseChannel::BeginAsyncRead signature.
Differential Revision: https://phabricator.services.mozilla.com/D125545
If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins
This is controlled by prefs.
Differential Revision: https://phabricator.services.mozilla.com/D126555
This is needed to make sure the experimental User Agent string is applied immediately after starting the browser, not just whenever the Nimbus data changes as part of the NimbusFeatures::OnUpdate handler.
Differential Revision: https://phabricator.services.mozilla.com/D126774
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Before this patch, we fetch HTTPS RR in `nsHttpChannel::MaybeStartDNSPrefetch`, which is too early. It's possible that this http request is blocked by an extension but we still send the query for HTTPS RR.
To improve this, we move the time of fetching HTTPS RR a bit late.
Differential Revision: https://phabricator.services.mozilla.com/D125931
Since `nsHttpTransaction::mConnection` could be `Http2Session` and `Http2Session` supports weak reference, we should make sure `Http2Session` to be always released on socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D125510
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Previously we called `ProcessCrossOriginEmbedderPolicy` in
`nsHttpChannel::ContinueProcessResponse1`, but we only loaded the cached
response headers in `ContinueProcessResponse3`, meaning that we incorrectly
reported a missing header for the revalidated resource.
This change moves the header checking calls to `ContinueProcessNormal` and
`AsyncProcessRedirection` instead, so they get executed after processing
the cached headers.
Differential Revision: https://phabricator.services.mozilla.com/D125184
This new pref will be used on android to enable high-value-only process
isolation. An initial version of high-value-only process isolation is
also implemented in this bug, using the permission manager to track
whether a site is high-value due to having served a
`Cross-Origin-Opener-Policy` header.
Future high-value permissions due to things like logging into a site and
OAuth flows can be tracked in the same way, by adding the permission to
the permissions database.
In the future, it might be valuable to provide UI for visualizing what
sites are considered high-value at any point in time, but this works
fine for now.
Differential Revision: https://phabricator.services.mozilla.com/D123127
This can happen during shutdown, when in `nsHttpNegotiateAuth::GetOrCreate()`
we assign `gSingleton` to a `new nsHttpNegotiateAuth` object but then it gets
cleared immediately by `mozilla::ClearOnShutdown` because we're already
shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D124893
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
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 supports channel cancelations with network markers.
Because of all the possible ways to stop a channel and hence all
possible end markers, it also introduces a new boolean to reduce the
complexity. Indeed it happens that 2 "end functions" are called, but we
need to insert only 1 end marker to have a well-formed result in the
Profiler frontend.
Differential Revision: https://phabricator.services.mozilla.com/D122111
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
Polling for write will in most cases always return immediately which causes necko to basically busy wait for the handshake to finish. To avoid thiis we will poll for READ and call OnSocketWritable to drive the haandshake.
Differential Revision: https://phabricator.services.mozilla.com/D122582
fixes:
Bug 472823 SHA 256 Digest Authentication
Original patch by Teun van Eijsden
Tests added by Vit Hampl <mozilla@bugear.com>
Original patch updated and tests fixed by gstrauss
fixes:
Bug 281851 CVE-2005-2395 Wrong scheme used when server offers both Basic and Digest auth
fixes:
Bug 669675 failure to skip unknown HTTP authentication schemes in WWW-Authenticate
Differential Revision: https://phabricator.services.mozilla.com/D106241
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
The ANDROID #ifdefs are necessary because Nimbus does not yet support Android in Gecko. The planned UA experiment won't include Android, so that's not a problem.
Differential Revision: https://phabricator.services.mozilla.com/D121112
Going through each of the headers in the 304 response and setting it on the
cached response head will cause us to only keep the last instance when
duplicate header names are present.
We should instead use the GetHeader method which properly handles merging the
response.
Differential Revision: https://phabricator.services.mozilla.com/D121527
The ANDROID #ifdefs are necessary because Nimbus does not yet support Android in Gecko. The planned UA experiment won't include Android, so that's not a problem.
Differential Revision: https://phabricator.services.mozilla.com/D121112
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
h2 proxy bug 1563538 added a temporary "network.http.spdy.bug1563538" pref in case its tunnel stream fix needed to be disabled quickly. That was almost two years ago (Firefox 68) and we haven't needed to disable this pref yet, so we can probably remove this pref and the old code paths now.
Differential Revision: https://phabricator.services.mozilla.com/D119942
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
When a navigation redirects, the principalToInherit is reset back to a null
principal for security reasons. This helps prevent a redirect from loading
attacker controlled content with the wrong principal. This patch gives this new
principalToInherit a precursor origin based on the resource which is being
redirected.
One time when this may come up is when an extension redirects a http: request
to a `data:` URI through the request API. Before this change, the load would
complete with a precursorless null principal, but after this change the
precursor refers to the redirected-from URL.
Depends on D119690
Differential Revision: https://phabricator.services.mozilla.com/D119691
This leaves the AsyncOpenFinal function because it is
used for Socket Process launch.
It adds some includes to fix Unified Builds.
Differential Revision: https://phabricator.services.mozilla.com/D119638
Jesse Schwartzentruber
Nika Layzell
Kershaw Chang
ssummar
Gijs Kruitbosch
Butkovits Atila
Manuel Bucher
Neil Deakin
Cristian Tuns
Dragana Damjanovic
Alexandru Michis
Andreea Pavel
Andi-Bogdan Postelnicu
Valentin Gosu
Gerald Squelart
Dimi
Csoregi Natalia
Norisz Fay
Sean Feng
somdatta
Noemi Erli
Shane Caraveo
Marian-Vasile Laza
Narcis Beleuzu
Sandor Molnar
Hannah Peuckmann
criss
Andrei Oprea
Michael[tm] Smith
Iulian Moraru
Yury Delendik
Cosmin Sabou
Luca Greco
Jens Stutte
june wilde
Emilio Cobos Alvarez
Dennis Schubert
Nicklas Boman
Benjamin Peterson
Florian Quèze
Andi-Bogdan Postelnicu
Julien Wajsberg
Eden Chuang
Glenn Strauss
Paul Zuehlcke
Magnus Melin
Chris Peterson
Dorel Luca
Tim Huang
Kashav Madan
Mike Kaply
Tom Ritter
Nihanth Subramanya