According to the W3C discussion we should allow websocket URIs to be
reported aside from http/https/ftp ones.
This rewrites things slightly and updates comments to clarify.
We do retain the non-standard reduction to origin only in case the
report is for cross-origin URIs (stops leaking full URIs to the CSP
reported destination).
See https://github.com/w3c/webappsec-csp/issues/735
Per the CSP specification, content injected by extensions is meant to
be exempt from page CSP. This patch takes care of the most common case
of content injected by extension content scripts, which always have
expanded principals which inherit from the page principal.
To make this easier, de-virtualize BasePrincipal::Kind(), using CTOR
initializers instead.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
Currently following Mozilla putting stuff in /dom for additional porting,
but it's actually the wrong location since it belongs in /netwerk with
the other code that deals with http headers.
For sake of ease of use, converted to boolean functions that just assume "false"
in case of errors.
Note: Mozilla makes special arrangements for .onion addresses as well but
we explicitly do not adopt that. TOR browser can do that all day if it wants.
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
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."
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.
