It seems to me that this is the opposite - a tightening of policy. No?
Okay... I'll dig into this some more, a little later.
No, they added a pref for "relaxed" which is always true (i.e. ignore the restriction) except in their test suite.
Code: Select all
Examples of those prefs & their normal values:
network.http.sendRefererHeader 2
network.http.referer.XOriginPolicy 0
network.http.referer.XOriginTrimmingPolicy 0
network.http.referer.defaultPolicy 2
network.http.referer.defaultPolicy.pbmode 2
network.http.referer.defaultPolicy.trackers 2
network.http.referer.defaultPolicy.trackers.pbmode 2
network.http.referer.disallowCrossSiteRelaxingDefault true
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode true
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode.top_navigation true
network.http.referer.disallowCrossSiteRelaxingDefault.top_navigation false
network.http.referer.hideOnionSource false
network.http.referer.referrerLengthLimit 4096
network.http.referer.spoofSource false
network.http.referer.trimmingPolicy 0
Code: Select all
nsresult nsCORSListenerProxy::StartCORSPreflight(
...
rv = preflightChannel->SetNotificationCallbacks(preflightListener);
NS_ENSURE_SUCCESS(rv, rv);
// Start preflight
rv = preflightChannel->AsyncOpen2(preflightListener);
NS_ENSURE_SUCCESS(rv, rv);
// Return newly created preflight channel
preflightChannel.forget(aPreflightChannel);
return NS_OK;
Code: Select all
nsresult nsCORSListenerProxy::StartCORSPreflight(
...
rv = preflightChannel->SetNotificationCallbacks(preflightListener);
NS_ENSURE_SUCCESS(rv, rv);
// Per https://fetch.spec.whatwg.org/#cors-preflight-fetch step 1, the
// request's referrer and referrer policy should match the original request.
uint32_t referrerPolicy = nsIHttpChannel::REFERRER_POLICY_UNSET;
rv = reqCh->GetReferrerPolicy(&referrerPolicy);
NS_ENSURE_SUCCESS(rv, rv);
nsCOMPtr<nsIURI> requestReferrerURI;
rv = reqCh->GetReferrer(getter_AddRefs(requestReferrerURI));
NS_ENSURE_SUCCESS(rv, rv);
rv = preCh->SetReferrerWithPolicy(requestReferrerURI, referrerPolicy);
NS_ENSURE_SUCCESS(rv, rv);
// Start preflight
rv = preflightChannel->AsyncOpen2(preflightListener);
NS_ENSURE_SUCCESS(rv, rv);
// Return newly created preflight channel
preflightChannel.forget(aPreflightChannel);
return NS_OK;
}
So, effectively, browser implementations make the entire referrer part of the CORS spec totally moot. Great.
Well we should just be able to add this line, right, so it gets added to preflight? I mean, if that's what's expected by the web. And we can continue to do the right thing otherwise which is honor headers (contrary to other browsers)...
That's irrelevant because an OPTIONS request is sent as a preflight BEFORE the GET is sent, so that header will not be parsed (it's not in a preflight). as stated before those requests are by their nature insecure. And pale Moon applies the default, as a result, which is not "unsafe-url", unlike what Chrome and FF apparently do, unconditionally, with that added code.Kris_88 wrote: ↑2024-01-11, 12:30And, no, there is no RFC violation here, because the page (https://pay2.comgate.cz/status/5HAM-TUOL-T4GR) explicitly specified the "referrer-policy" header as "unsafe-url".
Of course, the OPTIONS request is sent before the GET request for the resource: