168768 2017-02-23 02:10:34 -0800 [XHR] Consider not canonicalizing known header names 2022-10-09 23:43:43 -0700 1 1 1 Unclassified WebKit DOM Safari Technology Preview Unspecified Unspecified RESOLVED CONFIGURATION CHANGED P2 Normal --- 171031 1 annevk webkit-unassigned achristensen ahmad.saleem792 ap cdumez rbuis rniwa youennf oldest_to_newest 1280230 0 annevk 2017-02-23 02:10:34 -0800 Test: http://w3c-test.org/XMLHttpRequest/getallresponseheaders-cl.htm. (I keep having the feelings I'm getting the component wrong, but there's really not that many components.) 1280313 1 youennf 2017-02-23 09:23:18 -0800 I am not sure the component really matters. Prefixing the bug title with [XHR] might be good enough? 1280319 2 ap 2017-02-23 09:38:00 -0800 Is there some reason for this proposed change? Pretty sure all browsers used to agree, there were web compatibility reasons, and canonicalizing just makes sense. 1280327 3 annevk 2017-02-23 09:59:15 -0800 I've found that Chrome and Edge don't agree with Firefox and Safari and the way Firefox does interning is problematic, so we're likely aligning with Chrome. (Thanks for the component/summary advice.) 1904287 4 ahmad.saleem792 2022-10-08 14:28:20 -0700 If I search for "Get All Response Headers" on WPT.FYI, Safari Technology Preview 155 passes all tests: https://wpt.fyi/results/xhr?label=master&label=experimental&aligned&view=subtest&q=get%20all%20response%20headers Do we need anything more here? Thanks! 1904415 5 annevk 2022-10-09 23:43:43 -0700 Thanks Ahmad, looks like this got sorted at some point. (The `-cl.htm` got merged into the `.htm` file in https://github.com/web-platform-tests/wpt/commit/b32391a796893529fa425c45b9e8b96d58d68440 and then it was moved and rewritten some, but it kept testing the same thing.)