Now that h2 is pretty well stable, and we're fairly confident in our hpack table implementation, it's worth hiding this logging without some extra hoops, as it's just a lot of noise in logs.
Differential Revision: https://phabricator.services.mozilla.com/D11406
--HG--
extra : moz-landing-system : lando
https://tools.ietf.org/html/rfc8441
This uses our existing http/2 CONNECT infrastructure (modified) to
enable the new extended CONNECT form defined by 8441, and pretend for
the websocket's sake that an http/2 stream is actually a socket. From
the websocket's point of view, this is relatively non-invasive - a few
things have changed (http response code, absence of some headers) versus
http/1.1 websockets, but for the most part, the websocket code doesn't
care.
Differential Revision: https://phabricator.services.mozilla.com/D8016
--HG--
extra : moz-landing-system : lando
When PR_Read/PR_White returns -1, we have to use ErrorAccordingToNSPR to get the error code. We need to close the transaction if the real error happens.
Differential Revision: https://phabricator.services.mozilla.com/D9674
--HG--
extra : moz-landing-system : lando
The inner window id here is used to log the error message to the right web console.
So, top level content window id should work properly if we can't get the inner window id directly from the request.
Differential Revision: https://phabricator.services.mozilla.com/D9497
--HG--
extra : moz-landing-system : lando
This moves the check for a non-http proxy from the socket transport callbacks in
nsHttpConnection to nsHttpChannel before the connection occurs.
MozReview-Commit-ID: CJIozDInXWz
Necko does not allow for a CONNECT only request to happen. This adds a flag
to signal an http channel should only CONNECT if proxied. This flag can only be
set if an HTTPUpgrade handler has been assigned. As proposed by rfc7639, an
alpn header will be included in the CONNECT request. Its value is determined by
the upgrade protocol passed to HTTPUpgrade.
The flag is added as part of nsIHttpChannelInternal because it is dependent on
HTTPUpgrade. It exists as a capability flag since the channel's transaction
needs to know to complete after a successful CONNECT. Also the transaction's
connection needs to know to stop writing transaction data after it CONNECTs or
if there's no proxy, and to not tell the transaction to reset.
If an nsHttpChannel has this flag set then the upgrade handler will receive the
socket after the CONNECT succeeds without doing tls if https.
In order to support xpcshell-test for this change, nsHttpConnectionMgr does a
little check to see if HTTPUpgrade callback is in JavaScript. If it is then
the callback is invoked on the main thread.
--HG--
extra : rebase_source : 96cdfe0e1ffe2f7dad7d12c83c22be92d118195a
extra : intermediate-source : 70710e9bf3d98488485c3265ebdea09683a42a80
extra : source : 25b4b531c10c4b2dae416fd7d744a63a32fed7e5
Previously, we were sending INTERNAL_ERROR, but that's not really true. Firefox hasn't hit an error, we're just shutting down. It makes more sense to tell the peer we're not messed up, just going away nicely.
Depends on D8437
Differential Revision: https://phabricator.services.mozilla.com/D8439
--HG--
extra : moz-landing-system : lando
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
