Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 <[email protected]> Commit-Queue: Matt Menke <[email protected]> Cr-Commit-Position: refs/heads/master@{#601776} -- wpt-commits: 89637ce97bb8073a2db5182fc100125acba01481 wpt-pr: 13663
- Loading branch information