Make sure the mPrivateBrowsingId of Origin Attributes is consistent
between LoadInfo and LoadContext.
For chrome docshell, its mPrivateBrowsingId remains 0 even if its
UserPrivateBrowsing() is true (bug 1278664). So we sync the
mPrivateBrowsingId field in LoadInfo in the same way.
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.
netwerk/protocol/http/nsHttpHeaderArray.h:96:63 [-Wshadow] declaration shadows a field of 'mozilla::net::nsHttpHeaderArray::nsEntry'
netwerk/protocol/http/Http2Session.cpp:2766:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/HttpBaseChannel.cpp:1886:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/HttpChannelChild.cpp:265:53 [-Wshadow] declaration shadows a field of 'mozilla::net::AssociateApplicationCacheEvent'
netwerk/protocol/http/HttpChannelChild.cpp:266:53 [-Wshadow] declaration shadows a field of 'mozilla::net::AssociateApplicationCacheEvent'
netwerk/protocol/http/HttpChannelChild.cpp:2566:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/HttpChannelParent.cpp:397:17 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/InterceptedChannel.cpp:276:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/InterceptedChannel.cpp:285:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/SpdySession31.cpp:2177:14 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsCORSListenerProxy.cpp:304:30 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpChannel.cpp:796:17 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpChannel.cpp:4474:35 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpChannel.cpp:5915:18 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpConnection.cpp:982:21 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpConnectionMgr.cpp:1220:43 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpConnectionMgr.cpp:1240:43 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpConnectionMgr.cpp:2247:27 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpConnectionMgr.cpp:2758:23 [-Wshadow] declaration shadows a local variable
netwerk/protocol/http/nsHttpPipeline.cpp:709:30 [-Wshadow] declaration shadows a local variable
* Rename SchedulingContext to RequestContext
* Move SetLoadGroupUserAgentOverride to nsHttpChannel
* Cache the userAgentOverride in RequestContext instead of LoadGroup
MozReview-Commit-ID: FQS9uSRR8kd
In the non-e10s case, this is done by simply avoiding to set the
LOAD_BYPASS_SERVICE_WORKER flag when we detect a non-internal redirect
in the manual redirect mode.
The e10s solution is a bit more complicated. Only the child process
knows whether a URI needs to be intercepted, so we piggy back on the
code written to support the |event.respondWith(Response.redirect())|
case where we know in the child that the target of the redirect needs to
be intercepted.
This means that we need to check the same condition as in the non-e10s
case, but we also need to check whether the target of the redirection
needs to be intercepted, which means we need to properly take secure
upgrades into account as well. This is done by computing both whether
we should intercept and whether we should do a secure upgrade in
HttpChannelChild::SetupRedirect() and saving the information on the
HttpChannelChild for later usage in HttpChannelChild::AsyncOpen().
This is OK from a security perspective, since this decision only affects
whether the channel will be intercepted with the secure URI in the child
process. If the intercepting service worker decides to fall back to an
actual network request, we send the request to the parent process with
the original pre-upgrade URI, and the parent process will still be in
charge of whether a network visible HTTP request should be upgraded.
This is OK from a security perspective, since this decision only affects
whether the channel will be intercepted with the secure URI in the child
process. If the intercepting service worker decides to fall back to an
actual network request, we send the request to the parent process with
the original pre-upgrade URI, and the parent process will still be in
charge of whether a network visible HTTP request should be upgraded.
