191102 2018-10-31 00:52:00 -0700 Handling of 0x0B and 0x0C in HTTP header values 2018-11-09 08:51:56 -0800 1 1 1 Unclassified WebKit DOM WebKit Nightly Build Unspecified Unspecified RESOLVED INVALID InRadar P2 Normal --- 191116 1 annevk webkit-unassigned cdumez webkit-bug-importer youennf oldest_to_newest 1473631 0 annevk 2018-10-31 00:52:00 -0700 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. 1473671 1 annevk 2018-10-31 04:12:24 -0700 This can be a little security-sensitive: https://github.com/web-platform-tests/wpt/pull/13815. 1473751 2 cdumez 2018-10-31 09:45:55 -0700 I suspect an underlying CFNetwork issue here as I don't think WebKit is doing the parsing itself here? 1474058 3 annevk 2018-11-01 02:47:50 -0700 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.) 1474059 4 webkit-bug-importer 2018-11-01 02:49:20 -0700 <rdar://problem/45725476> 1476923 5 cdumez 2018-11-09 08:51:56 -0800 Confirmed as a CFNetwork bug so we forwarded the issue to them. No action should be needed on WebKit side so closing this bug.