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.
The controller needs to be able to handle redirects.
HttpChannelParentListener is a listener object that can attach to
multiple HttpChannelParent objects as part of a single logical Necko
channel (meaning that the listener object will be reused for redirected
channels) so it seems like the better choice for the object that should
implement nsINetworkInterceptController. This patch moves the
implementation of the nsINetworkInterceptController interface to
HttpChannelParentListener.
Doing this work in StartRedirectChannelToURI() was causing us to not set
the bypass service worker flag properly in the case of real HTTP redirects.
This patch also fixes the incorrect test expectation value.
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Additionally, make GetSubstitution return the URIs for the three special
"host names" through GetSubstitutionInternal, replacing what was originally
added in bug 257162. Those changes from bug 257162 relied on the
resource:app string being handled by nsXREDirProvider::GetFile, but that was
removed in bug 620931, effectively making that code now in
GetSubstitutionInternal useless.
The meaning of resource:///, resource://app/ and resource://gre/ needs to
remain constant. Unfortunately, the model of the resource protocol handler
is that it is possible to set substitutions that change their meaning.
So, we forbid setting overwriting the substitutions for those three
special "host names".
Unfortunately, with e10s, the full list of substitutions is also sent to
the content process, which then sets substitutions, making it harder to
know in which cases SetSubstitution is valid for those three "host names"
or not.
So instead of trying to find the right heuristics, use the recently added
SubstitutingProtocolHandler::ResolveSpecialCases API to handle the three
"host names" instead of storing them as "normal" substitutions.
Still actively reject SetSubstitution with the three special "host names"
so as to find issues such as bug 1224000 instead of allowing the chrome
manifest entry and have it silently ignored.
Ehsan Akhgari
Patrick McManus
Nicholas Hurley
Wes Kocher
Jason Duell
Jeff Walden
Mike Hommey
Shih-Chiang Chien
Ben Kelly
Carsten "Tomcat" Book
Christoph Kerschbaumer
Kannan Vijayan
Kris Maglione
Henry
Sebastian Hengst
Gian-Carlo Pascutto