- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
multipart/x-mixed-replace loads don't start a new load for parts other than the first,
they just call OnStartRequest/OnStopRequest for every part. The nsDocShell code was
trying to set the active entry to the loading entry for these loads, but because we
never started a new load after the first part, the loading entry would be null and we'd
just clear the active entry. history.replaceState would then try to replace the active
entry, but finding none it would just add a new one.
Differential Revision: https://phabricator.services.mozilla.com/D138464
Since both DnsAndConnectSocket and nsHttpTransaction use HttpActivityDistributor, let's refactor this a bit by moving some duplicate code to nsHttpHandler.
This patch also makes it possible to test ECH activity for Http3 case.
Differential Revision: https://phabricator.services.mozilla.com/D138893
Since both DnsAndConnectSocket and nsHttpTransaction use HttpActivityDistributor, let's refactor this a bit by moving some duplicate code to nsHttpHandler.
This patch also makes it possible to test ECH activity for Http3 case.
Depends on D138892
Differential Revision: https://phabricator.services.mozilla.com/D138893
This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
Firefox version 100 will ship on 2022-05-03. The Webcompat team can use Firefox's site interventions to spoof a version 99 UA for individual sites broken by a three-digit version number. But Firefox’s site interventions can’t override the UA for enterprise intranet sites we don't know about.
This patch adds a new "network.http.useragent.forceVersion" pref that enterprise admins can set to a known-good UA version (like 99) in an enterprise policy file. If the pref has a non-zero value, then override the User-Agent string's Firefox version. The value 0 means use the default Firefox version.
We can remove this pref in Firefox 103 after the next ESR is branched (version 102 on 2022-06-28). Enterprise users can use ESR 102 with forceVersion pref = 99 until the next ESR in mid-2023. Hopefully they can fix their broken intranet sites by that time.
Differential Revision: https://phabricator.services.mozilla.com/D137929
Monitor Firefox 100 experiment enrollment in the parent process. If the user gets enrolled in the experiment, the parent process will set the forceVersion100 pref in other processes. The forceVersion100 pref can also be set by the "Firefox 100" option in the Nightly Experiments settings.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135315
Monitor Firefox 100 experiment enrollment in the parent process. If the user gets enrolled in the experiment, the parent process will set the forceVersion100 pref in other processes. The forceVersion100 pref can also be set by the "Firefox 100" option in the Nightly Experiments settings.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135315
Monitor Firefox 100 experiment enrollment in the parent process. If the user gets enrolled in the experiment, the parent process will set the forceVersion100 pref in other processes. The forceVersion100 pref can also be set by the "Firefox 100" option in the Nightly Experiments settings.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135315
This is no longer necessary as the Quantum DOM project is no longer
happening, and removing support simplifies various components inside of
IPDL.
As some code used the support to get a `nsISerialEventTarget` for an
actor's worker thread, that method was replaced with a method which
instead pulls the nsISerialEventTarget from the MessageChannel and
should work on all actors.
Differential Revision: https://phabricator.services.mozilla.com/D135411
Facebook responds with 408 when a HTTP/3 connection has been idle for too
long. This is problematic since there are no caching headers added to the
response and it causes application errors if the response is loaded from
the cache.
Differential Revision: https://phabricator.services.mozilla.com/D136116
Change spelling in both network.http.http3.priorization and
network.http.http3.send_background_tabs_deprioritization config option
Differential Revision: https://phabricator.services.mozilla.com/D135689
It is an edge case that InterceptedHttpChannel::Cancel() could be called before calling AsyncOpenInternal().
In the case, mTimeStamp status would be Created and we should not record any time stamp for InterceptedHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D134775
Add a PlacesPReviews.jsm module that offers an alternative long term storage of
thumbnails or images. Previews are stored using md5 hash of the page url, in WebP format.
Removals happen using the moz_previews_tombstones table, orphans removal happens
on Places weekly maintenance.
The same moz-page-thumb: protocol that is currently used for volatile thumbnails,
can be used with Places previews, by using "places-previews" as host.
All the feature is behind the places.previews.enabled pref, not enabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D131916
Add a PlacesPReviews.jsm module that offers an alternative long term storage of
thumbnails or images. Previews are stored using md5 hash of the page url, in WebP format.
Removals happen using the moz_previews_tombstones table, orphans removal happens
on Places weekly maintenance.
The same moz-page-thumb: protocol that is currently used for volatile thumbnails,
can be used with Places previews, by using "places-previews" as host.
All the feature is behind the places.previews.enabled pref, not enabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D131916
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
The Http3Stream’s received side has one state, i.e. READING_INTERIM_HEADERS. The stream transitions into this state when 1xx response is received and it transitions back to BEFORE_HEADERS as new headers are expected. As with the final headers the 1xx headers are stored into mFlatResponseHeaders and they are picked up by the HttpTransaction from there.
neqo makes sure that response headers and data are received in the right order, e.g. 1xx cannot be received after a non-1xx response, fin cannot follow 1xx response, etc.
Differential Revision: https://phabricator.services.mozilla.com/D132831
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
In 1738984 we added this early return when the method is called during
shutdown to prevent NSS from being initialized and to fail things
as early as possible.
However, this check belongs at the top of the method, not after the
allocation.
Differential Revision: https://phabricator.services.mozilla.com/D133335
Most important changes:
- Neqo API now only use StreamId instead of u64 for the stream ids
- The server side API has send_headers, send_data and stream_close_send instead of a single set_response. Important change is also that send_data does not accept more data than the flow control allows. Set_response used to accept all data unconditionally. Therefore now we need to listen to DataWritable events.
Differential Revision: https://phabricator.services.mozilla.com/D132594
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
Most important changes:
- Neqo API now only use StreamId instead of u64 for the stream ids
- The server side API has send_headers, send_data and stream_close_send instead of a single set_response. Important change is also that send_data does not accept more data than the flow control allows. Set_response used to accept all data unconditionally. Therefore now we need to listen to DataWritable events.
Differential Revision: https://phabricator.services.mozilla.com/D132594