... as they otherwise appear in the about:networking list as "false"
while having been resolved by TRR.
MozReview-Commit-ID: 9g9fUExvyjS
--HG--
extra : rebase_source : 3098b7c3f7d01e55f5a8c031fc6a73e53f7edb05
... to avoid a catch-22 as CP needs name resolve to work.
MozReview-Commit-ID: DC1CjlUy4cJ
--HG--
extra : rebase_source : 3bc0f146071f04757d44b76f352e48b2abb4dad0
Previously it would store the time even for early AAAA responses that
weren't used until the A response came in, thus getting the timing
wrong.
MozReview-Commit-ID: KctUjMjH5FR
--HG--
extra : rebase_source : fafd7ad25cd1b7a43d4b4a5653600cad830b471d
To prevent it from sitting waiting for an event that was sent before the
TRRService started.
MozReview-Commit-ID: 9F0IlWGdA9O
--HG--
extra : rebase_source : 6a70210a4e538d8a1b240684a0b3ed5fed38e6ad
Otherwise it will just load back the same (problematic) addresses from the
cache again the second time. This introduces a new resolver bit
(REFRESH_CACHE) that also invalidates the existing cache entry while doing the
new resolve.
MozReview-Commit-ID: 5Bc2KiAGYYA
--HG--
extra : rebase_source : ae368c88a5db27f0980b9928439d27588bc84815
DNSRequestChild's constructor takes `const nsCString&` parameters. If
you have a `const nsACString&` argument to pass in to the constructor,
you're forced to construct a temporary nsCString object to satisfy the
prototype. But the temporary string will just get copied inside the
constructor and you'll have to destroy the temporary string object you
created.
Let's skip all this, and just have DNSRequestChild take `const
nsACString&` arguments instead, and avoid the temporary object.
Early AAAA responses might cause issues on hosts without working native
IPv6 connectivity, of course especially notable in TRR-only mode.
MozReview-Commit-ID: 6ZqE6AKnucH
--HG--
extra : rebase_source : ff42cb8daf941a3fa1f7e783c76d823e879024c3
RFC 1035 section 4.1.1 documents this bit as:
RD - Recursion Desired - this bit may be set in a query and is copied
into the response. If RD is set, it directs the name server to pursue
the query recursively. Recursive query support is optional.
MozReview-Commit-ID: 8iHDgNtA1L1
--HG--
extra : rebase_source : a29010a2894fd00ebfbfb869f5938cf507345a2f
... and remove Cancel() from nsHostRecord::RemoveOrRefresh since we
don't need to cancel TRR resolves due to network changes.
MozReview-Commit-ID: Akuhpzgg4N5
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
... and also store allow-rfc1918 bool locally to remove later accesses
to TRRservice.
MozReview-Commit-ID: KkO4u2N9gfE
--HG--
extra : rebase_source : 2fdfecb127987cdbfdccd0e77f7b4bb65f6f5f5d
When the native resolve needs to run again, the rec->mResolving counter
must not be decreased, as otherwise it triggers an assert when the next
resolve completes.
MozReview-Commit-ID: 3UQGkDSOmGi
--HG--
extra : rebase_source : 1caf047070a95b451acf0ddca6b5986f4e4d7c69
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Daniel Stenberg
Dorel Luca
Nathan Froyd
Florian Quèze
Ciure Andrei
Valentin Gosu
nbeleuzu@mozilla.com
Andrew McCreight
Kris Maglione
Cosmin Sabou
Brindusan Cristian
Jeff Hemphill
Phil Ringnalda
Csoregi Natalia