Responses with a single erroneous \n|LF in their header lines trigger a download in WebKit Desktop (and in Firefox, Chromium). In WebKit Mobile the response is instead displayed as a plain text file. Depending on where the LF occurs, headers before it even have effect (e.g., COOP). I would expect the same behavior on mobile and desktop. Response 1, COOP is active on WebKit mobile: http://sub.headers.websec.saarland/_hp/tests/window-references-coop.sub.html?resp_type=parsing&browser_id=1&label=COOP&first_id=23990&last_id=23990&scheme=http&t_resp_id=23990&t_element_relation=direct_direct&t_resp_origin=https://headers.webappsec.eu ``` HTTP/1.1 200 cross-origin-opener-policy: same-origin-allow-popups\n more headers body ``` Response 2, COOP is not active on WebKit mobile: http://sub.headers.websec.saarland/_hp/tests/window-references-coop.sub.html?resp_type=parsing&browser_id=1&label=COOP&first_id=22059&last_id=22059&scheme=http&t_resp_id=22059&t_element_relation=direct_direct&t_resp_origin=https://headers.webappsec.eu ``` HTTP/1.1 200 \ncross-origin-opener-policy: same-origin more headers body ``` Another question is whether the download dialog window should be "accessible", i.e., "window.open.opener" returns "window" (WebKit desktop, Chrome and Firefox on android), or whether it should be "null" (Chrome and Firefox on desktop).
<rdar://problem/126913847>