In certain cases (such as the case from bug 1050329, where a server claims to speak h2, but really doesn't), we will end up trying every connection to that server as h2 before falling back to http/1.1. Once we know a server is very badly behaved, it doesn't make sense to keep trying h2 (at least for the current browsing session). This adds an in-memory blacklist of origins & conninfos to not try h2 on, so we don't waste round trips trying h2, failing, and then dialing back with http/1.1 except for the first connection to an origin.
Depends on D8436
Differential Revision: https://phabricator.services.mozilla.com/D8437
--HG--
extra : moz-landing-system : lando
This is kind of like the previous patch (where we had a not-very-friendly user experience shutting down misbehaving h2 sessions), but in this case the server has proven to us that it can speak a minimum of h2, so we don't want to just fallback. Instead, when we send a GOAWAY frame because we have detected some error on the part of the server, if it's a top-level page load, we'll show an error page explaining that the server spoke bad http/2, and the site admin(s) need to be contacted. We already did this for INADEQUATE_SECURITY (which is its own special case still), but that didn't cover all the cases.
Differential Revision: https://phabricator.services.mozilla.com/D8436
--HG--
extra : moz-landing-system : lando
Previously, we would just let these fail. But, when a peer claims to speak h2 via ALPN, and then plainly doesn't speak h2 (by not doing the opening handshake properly), we should re-try any transactions dispatched to that session using http/1.1 only. No use in giving the user a horrible experience. We will also collect telemetry on how often we have sessions where this happens, so we can see how big of a problem this is (and thus if we need to do any kind of outreach).
Depends on D8432
Differential Revision: https://phabricator.services.mozilla.com/D8433
--HG--
extra : moz-landing-system : lando
Previously this was a macro, but in later patches in this series, I want to make the macro a bit smarter. There's no particular need to have it as a macro (and macros that return from functions are often considered no-nos), so this makes it a method on the session, instead.
Differential Revision: https://phabricator.services.mozilla.com/D8432
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : rebase_source : 43d92c631b964c52b551a700b0954276e91695d6
extra : source : 7f9d03c29a6ffd82c1b5e17c14e27a2ae9d64434
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : rebase_source : eb4961f05a52e557e7d2d986d59e0a2cf18a3447
extra : source : dd1c31ea78c2b15d14750d137037a54d50719997
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--HG--
extra : moz-landing-system : lando
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : moz-landing-system : lando
Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Differential Revision: https://phabricator.services.mozilla.com/D8878
--HG--
extra : moz-landing-system : lando
Right now, as soon as we receive an alt-svc header or frame for an origin, we will overwrite any mapping we already have for that origin, even if it's still valid. This means that, should validation fail for the new mapping, we will have blown away a perfectly usable alt-svc mapping for no good reason. This patch prevents us from overwriting until we know the new mapping is good.
Differential Revision: https://phabricator.services.mozilla.com/D8747
--HG--
extra : moz-landing-system : lando
OPTIONS preflights inherit the original request's referrer and referrer policy
Differential Revision: https://phabricator.services.mozilla.com/D7801
--HG--
extra : moz-landing-system : lando
"Gecko trail" is the term used by MDN [1] for the YYYMMDD build date in the UA string's "Gecko/" token. Build ID is a YYYYMMDDHHMMSS build timestamp. Use LEGACY_BUILD_ID to spoof navigator.buildID. Use LEGACY_UA_GECKO_TRAIL to construct the UA string.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
Differential Revision: https://phabricator.services.mozilla.com/D7983
--HG--
extra : rebase_source : e2a4d7579d419046f0bad6290078f9a652a770d8
extra : source : 8a26c8598528722a8920513c7fdfea40aefe0dbc
Previously, we had not put pushed streams in the priority tree, we just
let them be top-level items in the tree. With this change, we will put
them into the tree initially based on the priority of the associated
stream. The only exception is if the associated stream is either a
Leader or Urgent Start (in which case, we will turn the pushed streams
into followers).
Once the pushed stream is matched with a request generated by gecko,
that pushed stream will be re-prioritized based on the priority gecko
has for the request, just like a regular pulled stream.
This also allows us to re-prioritize pushed streams into the background
on tab switch (we assume that, before they are matched, they belong to
the same window as the associated stream).
Differential Revision: https://phabricator.services.mozilla.com/D7223
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
There was an earlier fix to this, that fixed part of the issue, but that
fix was racy. In the case where the transaction was matched with the
pushed stream before the pushed stream received its END_STREAM, and the
response headers did not include a content-length, the transaction would
never notice that the data was done being sent. When that transaction
was necessary for the load event to fire, the page would get stuck in
the loading state until the user explicitly cancelled.
This new patch ensures that the transaction will notice the EOS by
making sure the pushed stream gets inserted into the list of push
streams with data in the case described above. (The previous patch,
which is still in the tree, is still necessary, but not sufficient, to
fix the issue.)
Differential Revision: https://phabricator.services.mozilla.com/D7298
--HG--
extra : moz-landing-system : lando
The test used to assume that the load event didn't matter and so
the expected values had to be updated to match the new behavior.
A new "slowIFrame" test was added to capture what was previously
tested by the "badIFrame".
Differential Revision: https://phabricator.services.mozilla.com/D7031
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
Remove various calls to SetCapacity() that fall into various misuse categories:
1) Mistakenly believing that the caller should advice the string about zero
terminator.
2) Cases where a single append does the right computation on its own.
3) Calling SetCapacity() with a constant when the string is self-allocated
and could be an nsAuto[C]StringN and the string doesn't get passed on
in a way that could benefit from a heap-allocated buffer.
4) Calling SetCapacity() before assigning a shared buffer to the string.
5) Calling SetCapacity() before calling a function that will either calls
SetLength() anyway or calls Adopt().
MozReview-Commit-ID: IKjfl5gLmcD
Differential Revision: https://phabricator.services.mozilla.com/D4672
--HG--
extra : moz-landing-system : lando
Simply replace the nsCString with nsDependentCSubstring to avoid copying the data. In this way, we can also avoid the potential OOM crash.
Differential Revision: https://phabricator.services.mozilla.com/D6685
--HG--
extra : moz-landing-system : lando
Right now, pushed streams don't get put in the priority hierarchy
anyway, and with the code as it was, we were sending an illegal PRIORITY
frame for stream 0. This prevents that from happening. We should
probably think about putting pushed streams in the priority hierarchy at
some point.
Differential Revision: https://phabricator.services.mozilla.com/D6500
--HG--
extra : moz-landing-system : lando
nsIAssociatedContentSecurity and nsISecurityInfoProvider are unused as of
bug 832834, so this patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5693
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
OnSocketTread doesn't work properly during shutdown because nsSocketTransportService2.cpp::gSocketThread is null.
We call gSocketTransportService->IsOnCurrentThreadInfallible() instead, just like we already do in HttpBackgroundChannelChild::ActorDestroy()
Differential Revision: https://phabricator.services.mozilla.com/D5050
--HG--
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
Introduce these new blocking state values:
const unsigned long STATE_COOKIES_BLOCKED_BY_PERMISSION = 0x10000000;
const unsigned long STATE_COOKIES_BLOCKED_TRACKER = 0x20000000;
const unsigned long STATE_COOKIES_BLOCKED_ALL = 0x40000000;
const unsigned long STATE_COOKIES_BLOCKED_FOREIGN = 0x80000000;
make counter increased when trackers are found
Differential Revision: https://phabricator.services.mozilla.com/D4068
--HG--
extra : rebase_source : 90da79fbb83271b2f7a8460ebd02aa2abb635305
extra : source : c476aa79a8ca991dc8ea1e5c2eab98e442dad406
so that such requests don't inadvertently reuse connections done that
might have used TRR.
MozReview-Commit-ID: 2bO4VCGSgOO
Differential Revision: https://phabricator.services.mozilla.com/D4693
--HG--
extra : moz-landing-system : lando
Previously (under TLS 1.2), we would avoid advertising h2 support if the
spec-mandatory suite was disabled. That suite is only required for TLS
1.2, though. We would like to offer h2 in more cases, so only check for
the mandatory suite if someone has turned off TLS 1.3.
Differential Revision: https://phabricator.services.mozilla.com/D4345
--HG--
extra : moz-landing-system : lando
Count number of requests/streams per connection done when the connection
was used for TRR.
MozReview-Commit-ID: 50NVSCcd6jy
Differential Revision: https://phabricator.services.mozilla.com/D4083
--HG--
extra : moz-landing-system : lando
Disable TRR at will without needing to toggle the pref.
MozReview-Commit-ID: 1Ept6kDrjN3
Differential Revision: https://phabricator.services.mozilla.com/D3399
--HG--
extra : moz-landing-system : lando
The mIsTrackingResource flag on nsIHttpChannel was split into two separate
flags depending on whether or not the resource is third-party. The correct
flag will be set by the channel classifier. Similarly, a new function was
introduced, GetIsThirdPartyTrackingResource(), for those consumers (like TP)
who only care about third-party trackers.
The existing function, GetIsTracking(), will continue to look at both
first-party and third-party trackers (the behavior since first party
tracking was added to annotations in bug 1476324).
The OverrideTrackingResource() function now allows nsHTMLDocument to
override both mIsFirstPartyTrackingResource and
mIsThirdPartyTrackingResource, but since this function is a little dangerous
and only has a single user, I added an assert to make future callers think
twice about using it to opt out of tracking annotations.
Currently, only the default storage restrictions need to look at first-party
trackers so every other consumer has been moved to
mIsThirdPartyTrackingResource or GetIsThirdPartyTrackingResource().
This effectively reverts the third-party checks added in bug 1476715 and
replaces them with the more complicated check that was added in bug 1108017.
It follows the approach that Ehsan initially suggested in bug 1476715. It
also reverts the changes in the expected values of the tracking annotation
test since these were, in hindsight, a warning about this regression.
Depends on D3722
Differential Revision: https://phabricator.services.mozilla.com/D3723
--HG--
extra : moz-landing-system : lando
This refactoring is now unnecessary since the third-party check
is getting removed.
Differential Revision: https://phabricator.services.mozilla.com/D3720
--HG--
extra : moz-landing-system : lando
Count number of requests/streams per connection done when the connection
was used for TRR.
MozReview-Commit-ID: H7X06h8gVZY
Differential Revision: https://phabricator.services.mozilla.com/D3589
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
In some cases, such as for channels which have been opened from the parent
process, the top window URI isn't available. For such channels, the code
before this change would fail to compute the top window origin.
Besides this, we also need to do two extra things here:
* Call the http-on-modify-request observers after the Cookie header is set,
to ensure the Cookie header will be visible to them.
* Move the call to SetLoadGroupUserAgentOverride() to happen after that, in
order to preserve the existing respective ordering of that with regards to
when the http-on-modify-request observers run.
Please note that as things are right now, the http-on-modify-request observers
are unable to see the User-Agent header overrides through the loadgroup, which
seems suboptimal, but this patch aims to preserve the existing behavior of
these observers.
This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
"spdy.default-hpack-buffer" was incorrectly
written as "spdy.hpack-default-buffer".
--HG--
extra : histedit_source : 28dfa00e0accb4e51239a2d31178944034b3eaf5
With this patch, EnterprisePoliciesContent.js will only be loaded whenever a check for isAllowed happens in content.
This patch also adds shortcuts to make sure that checks for about:blank, about:neterror and about:certerror are skipped
MozReview-Commit-ID: AdMrolJqouN
--HG--
extra : rebase_source : 0949427c78fe26743294c0c1b43844f0154003b7
