Bug 191102
| Summary: | Handling of 0x0B and 0x0C in HTTP header values | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Anne van Kesteren <annevk> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | cdumez, webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 191116 | ||
| Bug Blocks: | |||
Anne van Kesteren
See https://github.com/web-platform-tests/wpt/pull/13471 for details. 0x0B and 0x0C get treated as whitespace, whereas they're not in HTTP. There might be differences here between the Darwin layer and the WebKit layer, and if so, that'd be bad.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Anne van Kesteren
This can be a little security-sensitive: https://github.com/web-platform-tests/wpt/pull/13815.
Chris Dumez
I suspect an underlying CFNetwork issue here as I don't think WebKit is doing the parsing itself here?
Anne van Kesteren
I think that might be correct. At least https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/loader/HTTPHeaderField.cpp looks correct when it comes to defining whitespace, but I'm not sure to what extent that's used for all the header parsing that happens inside WebCore.
(I was advised to nevertheless file potential CFNetwork issues here by Youenn et al at the most recent TPAC.)
Radar WebKit Bug Importer
<rdar://problem/45725476>
Chris Dumez
Confirmed as a CFNetwork bug so we forwarded the issue to them. No action should be needed on WebKit side so closing this bug.