Don't escape unicode control characters. While these characters would
break commands if present (i.e. non functional cURL) and could potentially
be sanitized to spaces, that would likely just move the goalposts again.
Following Mozilla here.
Follow-up to 15335ce39d1ea2ef4585a36a4d562a3894459a15
Trying to cross-platform sanitize causes issues escaping too much and
as a result mangling the curl commands that get spit out.
This reverts previously added Windows-specific escaping on POSIX and
vice versa.
Since we do not offer cross-platform copying as a curl command in devtools
anyway, it makes little sense to sanitize for the O.S. we're not running on
as we would not be using the command processor in such environments that
could trip over characters for the other O.S. This was previously added
as a defense-in-depth in case we would start offering this, but I see no
real reason to do so, anyway.
Also decided to in-line comments for readability instead of a bulleted
list in the function head.
Mozilla has taken similar steps because of fall-out, but they do offer
cross-platform "copy as curl" for corner cases, so they will have to
find solutions for a problem we won't have.
This leaves getAdjustedQuads alone because it lives in its own world and its
result gets sent over IPC. That leaves things in a bit of an intermediate state,
but that should be OK for now.
Backported from Mozilla bug 1186265.
Vim control lines were re-introduced or not entirely cleaned up.
This nukes them again.
Removing from the rest of js, caps, chrome, config, devtools, docshell,
image, intl. More to come.
Windows commonly fails to work because of --compressed, and its string
escaping needed improvement because of the complexities of argument
parsing in command windows.
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."
Moonchild
Andy
Francis Dominic Fajardo
FranklinDM
Martok
Job Bautista
roytam1
wolfbeast
Brian Grinstead
Gaming4JC
janekptacijarabaci