The HttpBaseChannel::IsBrowsingContextDiscarded() did always return
false if the loadGroup is not avaiable. But, this may not be correct for
the private channels if the private session has been ended. To fix this,
we make the function to check the global private browsing state
if the loadGroup is not available for private channels.
Depends on D184010
Differential Revision: https://phabricator.services.mozilla.com/D184479
We shouldn't block the iframe if the initial request doesn't have valid
headers, we should only check the final request.
Differential Revision: https://phabricator.services.mozilla.com/D180485
Add `ORB_BLOCK_REASON` to learn more about the reasoning of orb blocking in the wild.
Add ORB_BLOCK_INITIATOR to learn about the initiators. We can add more probes in the future if we want to target a specific initiator.
Differential Revision: https://phabricator.services.mozilla.com/D178102
nsHttpChannel::OnAuthCancelled calls nsHttpChannel::CallOnStartRequest
directly, effectively bypassing
HttpBaseChannel::ProcessCrossOriginSecurityHeaders, which is needed to
get CORP handling right.
Differential Revision: https://phabricator.services.mozilla.com/D177778
Add a separate check for spec breaking allows of certain MIME
types. Having this separated out means that we can make the rest of
the implementation behave exactly like spec.
Some tradeoffs that we need in the current state are:
* Allowing "application/dash+xml"
* Allowing "application/vnd.apple.mpegurl"
* Allowing "text/vtt"
* Allow all MIME types beginning with "audio/mpeg"
* Allow "text/plain" when there is a no-sniff header.
Differential Revision: https://phabricator.services.mozilla.com/D176821
We make sure to not send any data to the content process in case of
fetching an opaque resource. This is way to remain more web
compatible, but is also in conflict with the ORB specification.
Differential Revision: https://phabricator.services.mozilla.com/D173454
Content processes can do nothing to the responses of nsIContentPolicy::TYPE_BEACON,
nsIContentPolicy::TYPE_PING and nsIContentPolicy::TYPE_CSP_REPORT requests, so filter
them out of the ORB_DID_EVER_BLOCK_RESPONSE probe to not worry them for
web compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D173292
With HTTPS-First top-level loads can have a loading principal, so we
need to explicitly check the load info if we're doing a top-level
load.
Differential Revision: https://phabricator.services.mozilla.com/D171315
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
Since Bug 1802086, we strip authentication headers when redirected to a cross-origin page. However, the api ReferrerInfo::IsCrossOriginRequest used for determining whether a request is cross-origin cannot be used as it compares the triggering principal's uri with the redirected channel's uri. This comparison might sometimes yield to false positives.
For e.g consider the following scenario:
1. Load `https://example.org/` and send the following fetch request from browser console
```
fetch("https://test.com/some_location", {
"headers": {
"Authorization": "Token foo"
}
});
```
2. Server responds with a redirect to https://test.com/another_location
In the above scenario, the api ReferrerInfo::IsCrossOriginRequest will yield the above request as cross origin since the triggering principal uri here is example.com. Hence, this will be treated as cross-origin redirect resulting in removal of auth headers.
Thus ReferrerInfo::IsCrossOriginRequest has been replaced with nsScriptSecurityManager::CheckSameOriginURI where we directly compare the origins for the two requests.
Differential Revision: https://phabricator.services.mozilla.com/D170868
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
