To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Since we need the loadInfo to set up the IPDL connection, we move the logic to
do so from HttpChannelChild::AsyncOpen to HttpChannelChild::SetLoadInfo
via InitIPCChannel.
It would have been nicer to do so in HttpChannelChild::Init, but
I ran into issues with view-source channels, which required an ugly hack.
Also note that RemoteChannelExists() preserves the existing contract - it is
true between asyncOpen and onStopRequest - but the name is slightly off, as
the channel has already been open by the time we call asyncOpen. We will fix
this in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D12419
--HG--
extra : moz-landing-system : lando
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
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
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
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 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
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This fixes the "Assertion failure: PermissionAvailable(prin, aType), at nsPermissionManager.cpp:2341 when loading FTP URLs on debug builds"
MozReview-Commit-ID: 4eRGQ3hrUWo
--HG--
extra : rebase_source : 36516275b1fe0f266a08394484e19e0aecfbd671
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
This cleanup basically reverts the remaining bits of 93dcf59ff87
MozReview-Commit-ID: 9zimpjAkZyj
--HG--
extra : rebase_source : 7c2d573a0cd067f529f096472c1d543d8d598635
When writing to alt-data output stream fails for whatever reason, we now try to
truncate alternative data and keep the original data instead of dooming the
whole entry. The patch also changes how is the predicted size passed to the
cache. Instead of a dedicated method it's now an argument of openOutputStream
and openAlternativeOutputStream methods which fail in case the entry would
exceed the allowed limit.
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
This issue is triggered by off-main-thread ODA listener that return error cause from OnDataAvailable callback.
A CancelEvent will be prepend to event queue and trigger race condition between CompleteResume and EndForceEnqueueing.
The `mFlushing` is checked and set in separate critical sections, therefore two threads that executing MayFlushQueue
might both pass the `mFlushing` check and trying to call FlushQueue simultaneously.
The solution is to check and set `mFlushing` in single critical section, so we can guarantee that only one FlushQueue
can be executed at anytime.
In addition, resumption is postponed until no AutoEventEnqueuer is activated. Therefore, CompleteResume will only be
triggered while all the suspension requests and auto enqueue requests are finished.
MozReview-Commit-ID: HpxzgUqYm8C
--HG--
extra : rebase_source : 9be0d37bb4475a0817dafb6270585263160a9da1
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
The WebRequest API needs to know if a given window ID is at the top level, for
various reasons. It currently figures this out by mapping a channel's load
context to a <browser> element, which tracks its current top outer window ID.
But this is inefficient, and not friendly to C++ callers.
Adding the top window ID to the load info simplifies things considerably.
MozReview-Commit-ID: Fy0gxTqQZMZ
--HG--
extra : rebase_source : bb5b1e1b3294004ca5e713fc88c4e20652296e53
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
This flags is added in the http channel interface by which developers can control the TLS
connections from JavaScript code (e.g. Add-ons). Basically, all the changes accounted for
plumbing this TLS flags from JavaScript level to C++ code responsible for calling NSS
module. We also added a unit test to make sure that separate connections are created if we
use different tlsFlags. Basically we used a concrete set of flag values that covers the
edge cases and check the hashkey generated in the connection info.
--HG--
rename : netwerk/test/unit/test_separate_connections.js => netwerk/test/unit/test_tls_flags_separate_connections.js
Implements PerformanceTiming, nsITimedChannel, and devtools 'tls setup'
Also captures telemetry on this as we do for all other attributes of timedChannel
Also propogates some null transaction timings onto first real
transaction of a connection
MozReview-Commit-ID: 47TQJYVHnKC
--HG--
extra : rebase_source : a7723962986de0c2ab00d479a22c3f5fd185c8b2
Changes ExtensionProtocolHandler to use remote streams for
moz-extension loads of file and JAR URI's to allow for
filesystem read-access sandboxing.
Adds messaging to PNecko to allow child processes to
request an input stream or file descriptor for moz-extension
URI's.
Add ExtensionProtocolHandler singleton so that NeckoParent can
call methods directly and ExtensionProtocolHandler::NewFD
can use a new member variable |mFileOpenerThread| to open files.
Adds FileDescriptorFile, a limited implementation of nsIFile
that wraps a file descriptor, to be sideloaded into
nsJARChannels so that extension JAR files can be read
using a file descriptor without accessing the filesystem
directly.
MozReview-Commit-ID: 1pcnIpjz2yR
--HG--
extra : rebase_source : 9d7334778fc81837b11b98d4e32603f7e5eb3a27
Changes ExtensionProtocolHandler to use remote streams for
moz-extension loads of file and JAR URI's to allow for
filesystem read-access sandboxing.
Adds messaging to PNecko to allow child processes to
request an input stream or file descriptor for moz-extension
URI's.
Add ExtensionProtocolHandler singleton so that NeckoParent can
call methods directly and ExtensionProtocolHandler::NewFD
can use a new member variable |mFileOpenerThread| to open files.
Adds FileDescriptorFile, a limited implementation of nsIFile
that wraps a file descriptor, to be sideloaded into
nsJARChannels so that extension JAR files can be read
using a file descriptor without accessing the filesystem
directly.
MozReview-Commit-ID: 1pcnIpjz2yR
--HG--
extra : rebase_source : c3f2ede3dbfb29d98af6b194dbe58669d93d4197
Collect telemetry for all requests to get an exact percentage of
requests that are subject to HSTS priming, and how many result in an
HSTS Priming request being sent. Clean up telemetry to remove instances
of double counting requests if a priming request was sent.
HSTSPrimingListener::ReportTiming was using mCallback to calculate
timing telemetry, but we were calling swap() on the nsCOMPtr. Give it an
explicit argument for the callback.
Add tests for telemetry values to all of the HSTS priming tests. This
tests for the minimum as telemetry may be gathered on background or
other requests.
MozReview-Commit-ID: 5V2Nf0Ugc3r
--HG--
extra : rebase_source : daa357219a77d912a78b95a703430f39d884c6ab
This patch contains two parts below:
1. mNeckoTarget
Since almost all child channels in necko need mNeckoTarget to dispatch runnables to main thread, it seems worth to have a holder class of mNeckoTarget and ask child channels to inherit it.
2. ChannelEvent
A lot of classes in FTPChannelChild and HttpChannelChild inheriting ChannelEvent and override GetEventTarget. It should be worth to extract the same code and put it in the same space.
In order to provide more details context of how client arrived at the unsafe
page, particularly in redirect case, we may have to add more information to
redirect chains including:
- referrer (if any)
- remote address.
- URL
We may want to use an idl interface instead of nsIPrincipal to store these
information
MozReview-Commit-ID: 3Uh4r06w60C
If HttpChannelChild::Cancel is triggered off main thread while flushing channel event queue,
CompleteResume might be executed while the flush is about to be finished. In this case, queue resumption
will not be able to trigger the second queue flush because the previous one is not finished yet.
Therefore, the HttpChannelChild::Cancel will be sitted in the queue without executing.
MozReview-Commit-ID: GxnkiDUmEnw
--HG--
extra : rebase_source : d04268a04ab24c38bf6fa436526a04f77cd64805
PStunAddrsRequest.ipdl defines the new IPC protocol to get stun
addrs on the main process.
StunAddrsRequestChild requests the stun addrs from the parent.
StunAddrsRequestParent uses a static method on NrIceCtx to get the
stun addrs from the STS thead and sends the addrs back to the
child process.
NrIceStunAddr (nricestunaddr.{cpp|h}) wraps nr_local_addr and makes
it easier to serialize/deserialize over IPC.
NrIceStunAddrMessageUtils follows the pattern used by other Necko
IPC classes to define top-level serialization/deserialization
calls used by the IPC framework.
Modifications under netwerk/ipc are to connect the new IPC
protocol to get stun addrs to PNecko since it is a network
related IPC protocol.
MozReview-Commit-ID: GyEapBe5krl
--HG--
extra : rebase_source : c650d6aa4f7928bcae6032424303869074a755d4
HTTP/1.1 pipelines have been subsumed by the more effective mux of spdy, h2, and soon quic.
The feature was never able to overcome the limitations of HoL blocking
and TCP reset, and their impact on performance and reliability.
Fundamentally mux is the only way we should be approaching that problem.
The massive amount of code - mostly heuristics to try and deal with
the HoL problem (by classifying things onto different transactions,
timers for broken servers, etc..) has become a maintenance burden with
minimal value given the default off state of the feature.
h2 is the new (working) strategy.
--HG--
extra : rebase_source : 5794957c1f078ca435480724d3caf9bdd861b7de
This patch adds (and hooks up) a new service so that HTTP channels marked as
"Throttleable" will periodically be Suspend()ed and Resume()d when more
important operations are going (such as a page load).
While this patch is not responsible for marking channels as "Throttleable",
the general idea is that these would be less-important channels - background
downloads, beacons, etc, and perhaps even resources known to be trackers.
MozReview-Commit-ID: HEZsxS04rRK
--HG--
extra : rebase_source : 03cce85fe7df782e1f6e2da9e5a99997b796aba2
This patch tries to figure out which DocGroup or TabGroup a network request
belongs to and then assign the IPC actor to that group. A DocGroup roughly
corresponds to a document and a TabGroup to a tab. Once the assignment is
made, all incoming IPC messages will be labeled with that DocGroup/TabGroup.
MozReview-Commit-ID: EzGCeGdREHl
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
* Add PAltDataOutputStream.ipdl to be able to open an OutputStream to the cache entry in the child process
* AltDataOutputStreamChild/Parent are Main Thread only for now.
* Adds methods for reading and writing alt-data to nsICacheInfoChannel.idl
* Keep a ref of the cache entry after OnStopRequest in case the consumer tries to open the alt-data output stream
MozReview-Commit-ID: jlraDI97Hg
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
CloneOpenedToplevels, which is never called, is the only interesting
caller of CloneToplevel. And CloneToplevel, in turn, is the only
interesting caller of CloneManagees. Which means we can ditch all this
code for a decent amount of space savings, both in code and writable
static data (no more useless virtual function entries in vtables).
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
The patch also changes RemoteOpenFileChild::OpenNSPRFileDesc() so that it
cannot succeed with a null fd, so that checking just the return value is
sufficient.
--HG--
extra : rebase_source : cc40bbcf2a9991edc9d3da3fb624d27db50b4996
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Kershaw Chang
Andrea Marchesini
Emilio Cobos Álvarez
Sylvestre Ledru
Brian Hackett
Valentin Gosu
Ehsan Akhgari
Cosmin Sabou
Paul Vitale
Dorel Luca
Francois Marier
Dragana Damjanovic
Gurzau Raul
Noemi Erli
Liang-Heng Chen
Gabriele Svelto
Margareta Eliza Balazs
Chris Peterson
Andi-Bogdan Postelnicu
Ben Kelly
Alex Gaynor
Honza Bambas
Patrick McManus
Rob Wu
Michal Novotny
Sebastian Hengst
Tristan Bourvon
Nika Layzell
Christoph Kerschbaumer
Jonathan Kingston
Kate McKinley
Shih-Chiang Chien
Amy Chung
Eric Rahm
Tom Tung
shindli
evilpies@gmail.com
Wes Kocher
Ryan VanderMeulen
Kris Maglione
Nicholas Hurley
Michael Layzell
Sajjad Arshad
Carsten "Tomcat" Book
Shane Caraveo
Kershaw Chang
Nathan Froyd
Haik Aftandilian
Bill McCloskey
Phil Ringnalda
Junior Hsu
Thomas Nguyen
Ho-Pang Hsu
Michael Froman
Tim Huang
Emanuel Hoogeveen
Nicholas Hurley
Wei-Cheng Pan
Tomislav Jurin
Kan-Ru Chen
Josh Matthews
Nicholas Nethercote
Yoshi Huang
Nathan Froyd
James Andreou
Jason Duell
Iris Hsiao
Tom Tromey
Aaron Klotz
Alexandre Lissy