Since bug 822869 the referrer trimming has relied on using prePath when
trimming resulting in non-ASCII hosts being passed through in UTF-8 (or
whatever their encoding was.)
Prior to this patch, the logic when trimming was to generate the referrer
string using prePath and possibly nsIURL.filePath, then re-derive the
nsIURI from that string.
Concerned about the cost of introducing asciiPrePath just for this consumer,
I opted to have the code just combine the scheme and asciiHostPort to
approximate the prior use of prePath. (userPass is explicitly cleared by
the code.)
Concerned about weirdness/loss of fidelity in the nsIURI, I replaced the
code that re-derived the URI from the spec string with manual clearing
of the parts of the URI/URL we were not including. This may not be the
right thing to do.
I modified the existing Gecko-specific test coverage of SetReferrerPolicy.
The existing web platform tests and referrer policy didn't seem concerned
with this case, and the bug is indeed localized to a very small segment
of Gecko code. Note that the userReferrerTrimmingPolicy=1 bug case can
only be triggered by explicit user preference setting and this is only
tested in test_referrer.js. userReferrerTrimmingPolicy=2 need not be
set by preference if REFERRER_POLICY_ORIGIN or
REFERRER_POLICY_ORIGIN_WHEN_XORIGIN (when cross origin) is used.
The fetch spec has re-introduced "only-if-cached" mode which loads only from
the cache. There are privacy implications to this so for the time being it
is required that "same-origin" mode is used.
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
Failure to do this will result in the consumers of
nsIHttpChannel::GetReferrer() observing the wrong referrer. The test in this
patch shows the scenarios which would fail under such conditions.
Failure to do this will result in the consumers of
nsIHttpChannel::GetReferrer() observing the wrong referrer. The test in this
patch shows the scenarios which would fail under such conditions.
