Bug 1501150 [wpt PR 13663] - HttpStreamParser: Reject headers with nu…

…lls in them., a=testonly

Automatic update from web-platform-testsHttpStreamParser: Reject headers with nulls in them.

While the HTTP spec further limits what values are legal, nulls are
particularly concerning, and it's safest just to reject them. See
discussion here: whatwg/xhr#165

Chrome will be the first browser to reject nulls in responses, despite
there being wpt tests for this, so we'll have to keep an eye out for
breakages.

For reference, 0x00 through 0x1F aren't allowed in header values or
fields, (https://tools.ietf.org/html/rfc7230#section-3.2 - VCHAR
excludes those characters).  CRs and LFs are of course needed, and
0x0C and 0x0B are allowed by other specs for particular
header parsers, strangely.

This CL does not affect other code that can generate HTTP response
headers, which still uses the old behavior of just removing nulls.
ServiceWorkers, extensions, WebPackages, Dial (?), and various tests
still inherit the old behavior, since they create headers directly
with a method that can't fail.  It does introduce a new helper method,
however, that they should eventually be switched to use:
HttpResponseHeaders::TryToCreate().  We should probably put off
conversion until this successfully makes it to stable.

Bug: 832086
Change-Id: Ib75ac03a6a298238cafb41eaa5f046c082fd0bdf
Reviewed-on: https://chromium-review.googlesource.com/c/1291812
Reviewed-by: Asanka Herath <asankachromium.org>
Commit-Queue: Matt Menke <mmenkechromium.org>
Cr-Commit-Position: refs/heads/master{#601776}

--

wpt-commits: 89637ce97bb8073a2db5182fc100125acba01481
wpt-pr: 13663

UltraBlame original commit: 8fc01167cf39bf970ad99953b0776f4338ddca84

testing/web-platform/tests/cookies/http-state/chromium-tests.html

@@ -499,22 +499,6 @@
 chromium0022
 "
 }
-{
-file
-:
-"
-disabled
--
-chromium0023
-"
-name
-:
-"
-disabled
--
-chromium0023
-"
-}
 ]
 ;
 for