Since TRRService::MaybeSetPrivateURI() is the only case that can triggers a new confirmation when TRRService::ReadPrefs() is called, making ConfirmationContext::Handle() returns a boolean value should be enough for this case.
Differential Revision: https://phabricator.services.mozilla.com/D139107
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
This is needed because TRRService is a friend class of TRRService
(needed to provide access to private constructor). If we find a way to
have a friend destructor method then we would not need the wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D113312
- Adds CONFIRM_TRYING_FAILED confirmation state. We use this state when we retry confirmation after confirmation fails.
- Rename CONFIRM_TRYING to CONFIRM_TRYING_OK. We use this state when we try confirmation but no confirmation failure has happened.
- Rename CONFIRM_INIT to CONFIRM_OFF. We use this state whenever there is an event that would disable TRR - such as a TRR mode change.
- Add CONFIRM_DISABLED confirmation state. We use this state in mode3 or when confirmationNS=="skip"
- To potentially allow us to have the same behaviour as after Bug 1689113, specifically the we might be able to report TRRService::Enabled = true when retrying and the state is CONFIRM_TRYING_FAILED we added `network.trr.attempt-when-retrying-confirmation`
- After a large number of TRR failures occurs, we immediately trigger another confirmation and go into CONFIRM_TRYING_OK. This allows us to cope with a temporary increase in network latency that is smaller than 6s.
- We no longer trigger confirmation for nsIRequest::TRR_FIRST_MODE when the resolver mode is not TRR_FIRST. This allows us to simplify the code.
- test_trr_proxy.js now calls trr_test_setup() after it sets up the pac script to avoid confirmation causing non-local connections in tests.
- Moves all the confirmation state handing into HandleConfirmationEvent
Differential Revision: https://phabricator.services.mozilla.com/D107666
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This allows us to separate general TRR performance issues from "this user's
custom DoH server is slow or malfunctioning".
Any DoH servers domains that are not shipped by Firefox are reported as (other).
Differential Revision: https://phabricator.services.mozilla.com/D105602
- Adds new TRR* argument to CompleteLookup so we can extract the channel
status from the TRR request.
- Record event whenever the confirmation context changes
- NetworkID is recorded whenever we start a new confirmation attempt
- Captive portal status is updated based on observer notifications
- We keep a buffer of the last 32 confirmation results.
Differential Revision: https://phabricator.services.mozilla.com/D105173
CLOSED TREE
Backed out changeset 3c771d45563a (bug 1684040)
Backed out changeset 76e79151d53c (bug 1684040)
Backed out changeset 7a993eb7bfde (bug 1684040)
This patch adds a task that is dispatched to the background thread when TRR
is first enabled. This may mean during the TRRService initialization at
startup or later when the pref is flipped.
The task will call into rust_parse_etc_hosts which does the actual file
opening and parsing. We pass the path to the file, that being either
/etc/hosts or the Windows equivalent obtained by calling
SHGetSpecialFolderPathA.
The rust code opens the file and proceeds to read it line by line while
accumulating all the hostnames in an array. Since these files can be
quite large, on the order of several megabytes, we need to make sure we
don't block shutdown doing this - so once more than 100 domains have
accumulated in the array we call back into C++ code to add them to the
exclusion list. The callback will return true if we should continue to
parse the file or false otherwise.
We also change the tests to use "excluded" rather than localhost when
testing the excluded-domains prefs, since localhost is unually present
in /etc/hosts and may interfere with the test.
We also use an atomic sTRRServicePtr to make sure that we don't have
a data race between the TRRService being freed and the callbacks of the
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D90663