In order to respect the content blocking allow list permission, we have
to do an internal redirect to the unstripped URI. We can only do this by
using an internal redirect because the stripping was happened in loadURI
in the content process. At the moment, the content process doesn't know
the content blocking allow list principal for the cross-origin URI. So,
we don't know if we should skip the query stripping. To resolve this,
we have to redirect the chanell back to the unstripped URI in the parent
process where the permission is available.
Differential Revision: https://phabricator.services.mozilla.com/D116113
The patch makes the original redirect URI to be preserved in the
loadInfo of the redirect channel when query stripping happens during
redirects.
Differential Revision: https://phabricator.services.mozilla.com/D116112
This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
This change also records the VPN_DETECTED platform indication when the Mozilla VPN adapter is active. The same interface type (IF_TYPE_PROP_VIRTUAL - proprietary virtual interface) is commonly used for other VPN implementations, so this should cover more of our bases.
Additionaly we also detect this is one of the interfaces contains the string "VPN" in its FriendlyName or Description. We do this in order to detect less common VPN types.
This change means that users currently enrolled in doh-rollout that are running a VPN will not be using DoH. This is good as using DoH with a VPN might leak the user's real location by resolving domains differently. See bug 1628149 comment 27.
Differential Revision: https://phabricator.services.mozilla.com/D116463
- Make nsHttp::ResolveAtom lazily initialize the static atom table if empty
- Use a DataMutex to ensure locked access to the atom table
- Use nsCString in nsHttpAtom so strings can be shared/reference counted
- Add atomic sTableDestroyed so we don't reinit the atom table during shutdown
Depends on D114717
Differential Revision: https://phabricator.services.mozilla.com/D114718
DelayedDispatch, in all current implementations, will set up a timer sync and
then Dispatch() a runnable. Since the timer is set up before the Dispatch, there
is a theoretical chance that the timer fires and dispatches a TimerEvent to the
target thread before DelayedDispatch managed to do so. When this happens the
internal DelayedDispatch runnable exits early, i.e., in practice it never runs.
The chance increases dramatically if the Dispatch() to the target in question is
tail dispatched, since the time between DelayedDispatch and the tail could be
non-trivial.
This patch removes the assert that checks that all DelayedRunnables that have
run have also been scheduled, since per the above no such guarantee exists.
Differential Revision: https://phabricator.services.mozilla.com/D112876
- Make nsHttp::ResolveAtom lazily initialize the static atom table if empty
- Use a DataMutex to ensure locked access to the atom table
- Use nsCString in nsHttpAtom so strings can be shared/reference counted
- Add atomic sTableDestroyed so we don't reinit the atom table during shutdown
Depends on D114717
Differential Revision: https://phabricator.services.mozilla.com/D114718
fixes:
Bug 472823 SHA 256 Digest Authentication
Original patch by Teun van Eijsden
Tests added by Vit Hampl <mozilla@bugear.com>
Original patch updated and tests fixed by gstrauss
fixes:
Bug 281851 CVE-2005-2395 Wrong scheme used when server offers both Basic and Digest auth
fixes:
Bug 669675 failure to skip unknown HTTP authentication schemes in WWW-Authenticate
Differential Revision: https://phabricator.services.mozilla.com/D106241
