The original code (from bug 1200802) declared an XPCOM object as a static bare
pointer, which for future reference is probably never the right thing to do. It
might have worked if it was cleared before shutdown but it never was.
MozReview-Commit-ID: EMe7wgzm6zv
--HG--
extra : rebase_source : 572ce6822e297692bab3311a65e1143785b913c4
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
There's no need to allocate a completely new nsCString when all we want
to do is parse a character string into an integer. We can allocate a
dependent string instead, which will avoid some memory churn.
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
What we're really doing in CacheEntry::CheckRequest is checking:
a) Whether the method is contained in our allowed methods; and
b) Whether all of the headers are contained in our allowed headers.
nsTArray lets us check directly for containing elements, so let's use
that facility rather than rolling our own.
nsCaseInsensitiveCStringComparator ought to be cheap to construct, but
the object actually has a vtable to install and whatnot. So it's
beneficial to pull the construction of it outside of the headers loop.
The entries in mMethods and mHeaders aren't sorted in any special way,
so we can remove expired entries using UnorderedRemoveElementAt, which
is faster than RemoveElementAt.
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
mCleanedUp is a VarCache variable, which mirrors the canonical value of the
network.predictor.cleaned-up pref. When the canonical pref value is modified,
e.g. by SetBool(), then mCleanedUp is also updated.
But the updating relationship is one-way -- if mCleanedUp is modified, the
canonical value of the pref is not updated. Such an inconsistency is bad! For
example, Predictor.cpp will use mCleanedUp's value, but about:config will show
the canonical value.
(For this reason, VarCache prefs are meant to be read-only outside of libpref.
Bug 1436655 will enforce this.)
This patch changes mCleanedUp so it's not a VarCache variable, avoiding the
mirroring issue.
MozReview-Commit-ID: LIG02gMkRjF
--HG--
extra : rebase_source : 273b2372ce718b0f346695a0dc96a189cd3ba233
Older versions of clang complain about this code, with:
netwerk/protocol/http/nsCORSListenerProxy.cpp:230:5: error: default initialization of an object of const type 'const struct CheckHeaderToken' without a user-provided default constructor
Later versions of the standard were amended to make this not an error,
but clang still warns. Pacify clang by making the object not const.
