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."
A case of "one queue too many" here. Instead of worker runnables being sent to the main thread
where they are supposed to run, they are put in a task queue per-worker. This is devastating
for performance if many workers are running.
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, duplicate it to nsContentUtils as a util function.
This is a duplication because CSSValue uses stringbuffers and not nsStrings.
While Bug 1356060 - "Just use nsString in URLValueData" converts this use from stringbuffer to nsString, it builds on a bunch of vartype refactoring (nsString vs. nsAString, etc.) which is too much of a headache to deal with just to deduplicate this simple function.
* Part 1. Move IsLocalRefURL to nsContentUtils to reuse this function. (port-rewrite)
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, move it to nsContentUtils as a util function.
* Revert "Part 1. Move IsLocalRefURL to nsContentUtils to reuse this function. (port-rewrite)"
This reverts commit 19f010c62022e269f99066a8d90e3522fe31adaf.
* Part 1. Duplicate IsLocalRefURL to nsContentUtils to reuse this function.
`IsLocalRefURL` is originally designed to be used by URLValue only.
Since we need this function in SVGUseElement::LookupHref too, duplicate it to nsContentUtils as a util function.
This is a duplication because CSSValue uses stringbuffers and not nsStrings.
While Bug 1356060 - "Just use nsString in URLValueData" converts this use from stringbuffer to nsString, it builds on a bunch of vartype refactoring (nsString vs. nsAString, etc.) which is too much of a headache to deal with just to deduplicate this simple function.
* Part 2. Implement nsSVGEffects::GetBaseURLForLocalRef to export local-ref-url-resolving logic.
ResolveURLUsingLocalRef is designed to be internally used by nsSVGEffects::Get-{SVGEffect}-URI functions.
Since we also need it in SVGUseElement::LookupHref, make it public in nsSVGEffects.
* Part 3. Resolve local-ref in SVGUseElement::LookupHref by nsSVGEffects::GetBaseURLForLocalRef.
* Part 4. Reftest for using local-ref as xlink:href value.
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.
This resolves#717.
Note: this does not affect other applications because the platform
default is to use the "darknoise" background image for standalone
image, which effectively overrides a bg color.
NPAPI may handle a 307 redirect across different origins, while they
should only happen on same origin requests. Have the browser check
this before forwarding to NPAPI.
