| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Still allow this to be bypassed with a pref for those really rare corner
cases where images are loaded cross-origin by design and the session
hasn't been/can't be authenticated ahead of time.
|
| |
|
|
|
|
| |
tunnel.
|
|
|
|
|
|
| |
When PR_Read/PR_White returns -1, we have to use ErrorAccordingToNSPR
to get the error code.
We need to close the transaction if a real error happens.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Defaults to false if not configured.
|
|
|
|
|
|
| |
Apparently there is some functional and naming confusion here.
Backing out to re-land after evaluation and possible changes.
Tag #863.
|
|
|
|
|
|
|
| |
This adds a pref "network.http.opportunistic-encryption" that controls whether
we send an "Upgrade-Insecure-Requests : 1" header on document navigation or not.
This patch modifies the platform network parts. Default for the platform is "true".
Part 1 for #863
|
| |
|
|\
| |
| | |
Issue #792 - backport mozbug 1334776 - CVE-2017-7797 Header name interning leaks across origins
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
origins
Potential attack: session supercookie.
[Moz Notes](https://bugzilla.mozilla.org/show_bug.cgi?id=1334776#c5):
"The problem is that for unknown header names we store the first one we see and then later we case-insensitively match against that name *globally*. That means you can track if a user agent has already seen a certain header name used (by using a different casing and observing whether it gets normalized). This would allow you to see if a user has used a sensitive service that uses custom header names, or allows you to track a user across sites, by teaching the browser about a certain header case once and then observing if different casings get normalized to that.
What we should do instead is only store the casing for a header name for each header list and not globally. That way it only leaks where it's expected (and necessary) to leak."
[Moz fix note](https://bugzilla.mozilla.org/show_bug.cgi?id=1334776#c8):
"nsHttpAtom now holds the old nsHttpAtom and a string that is case sensitive (only for not standard headers).
So nsHttpAtom holds a pointer to a header name. (header names are store on a static structure). This is how it used to be. I left that part the same but added a nsCString which holds a string that was used to resoled the header name. So when we parse headers we call ResolveHeader with a char*. If it is a new header name the char* will be stored in a HttpHeapAtom, nsHttpAtom::_val will point to HttpHeapAtom::value and the same strings will be stored in mLocalCaseSensitiveHeader. For the first resolve request they will be the same but for the following maybe not. At the end this nsHttpAtom will be stored in nsHttpHeaderArray. For all operation we will used the old char* except when we are returning it to a script using VisitHeaders."
|
|/
|
|
|
|
|
|
| |
r=mayhemer
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.
|
|
|
|
| |
This resolves #776.
|
|
|
|
|
| |
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
|
|
|
|
| |
changed
|
| |
|
| |
|
| |
|
|
|
|
| |
PR #412
|
| |
|
| |
|
|
|
|
| |
Tag #288
|
|
|
|
| |
https://github.com/MoonchildProductions/moebius/pull/158
|
| |
|
|
|
|
| |
to match the spec
|
|
|
|
|
|
|
|
|
|
| |
VALIDATE_NEVER instead of LOAD_FROM_CACHE. r=mayhemer, a=RyanVM
--HG--
extra : source : 60fb09de57ec145923da102f856399d3323f632b
extra : amend_source : b42db87defcc5615773cfa4659af9ff5b9cd4b72
extra : intermediate-source : 599641c7992def734cb352d9413aa51bf0e9793f
extra : histedit_source : 1d42c837225bdf000d3a68bef46a862be87d4044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to avoid race. r=bagder, a=ritu
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : rebase_source : d6e6886402d1e0b0afed23c25a9fb18d8ca29ad6
extra : intermediate-source : cfc9afe916091e6449f7d748991e2a19187dc817
extra : source : 4ebdab0e332892378558817e30d0138c95199ce5
|
|
|
|
|
|
|
|
|
| |
MozReview-Commit-ID: 6irCJMAjzjW
--HG--
extra : rebase_source : 2357ab0b9d1d693dac9e5f4f16f34f370c6591b5
extra : intermediate-source : 48b9f6671588c3c2b8d3b4ea6ba1267f5e297f83
extra : source : bd315ae86709c3459a3dbf0778022ff3b1908723
|
|
|
|
|
|
|
| |
MozReview-Commit-ID: CD1l5vLB4yy
--HG--
extra : rebase_source : d74f8ca96dab4e0d25d79948fcddbf8dab98bb36
|
|
|
|
|
|
|
| |
PerformanceTiming
https://github.com/MoonchildProductions/moebius/pull/116
("/testing" and "/toolkit" in in the previous commit)
|
|\ |
|
| | |
|
| |
| |
| |
| | |
back to tls1.2,we should reconnect using tls1.3 without EarlyData
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Bug(s):
https://bugzilla.mozilla.org/show_bug.cgi?id=1340164
(native in moebius)
|
| | | |
|