HTML documents served without Content-Type header can cause download prompt in Safari

[robertknight]

When visiting https://www.wired.com/story/banning-white-supremacy-censorship-accountability/ through ViaHTML with Safari I got an unexpected prompt asking whether I wanted to allow downloads. Clicking "Yes" downloaded an empty file:

The URL for the download was listed as https://qa-viahtml3.hypothes.is/proxy/if_///usersync.getpublica.com/usersync?gpdr=0&consent=&us_privacy=

The raw response from upstream contains no Content-Type header:

[I]  ~/h/v/.t/dev > curl -i 'https://usersync.getpublica.com/usersync?gpdr=0&consent=&us_privacy='
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate, proxy-revalidate
Expires: 0
Pragma: no-cache
Vary: Origin
Date: Mon, 22 Feb 2021 17:54:27 GMT
Content-Length: 0

The proxied response also has no Content-Type header, but somewhere in the pipeline x-content-type-options: nosniff which may be preventing the browser from nevertheless detecting the content as HTML:

[I]  ~/h/v/.t/dev > curl -i 'https://viahtml3.hypothes.is/proxy/https://usersync.getpublica.com/usersync?gpdr=0&consent=&us_privacy='
HTTP/2 200
date: Mon, 22 Feb 2021 17:39:32 GMT
content-length: 0
set-cookie: __cfduid=d8630bbfd5e835d6658bed71e8ee143c81614015571; expires=Wed, 24-Mar-21 17:39:31 GMT; path=/; domain=.hypothes.is; HttpOnly; SameSite=Lax
cache-control: private, no-cache, no-store, must-revalidate, proxy-revalidate
vary: accept-datetime
content-location: https://viahtml3.hypothes.is/proxy/20210222173931/https://usersync.getpublica.com/usersync?gpdr=0&consent=&us_privacy=
x-robots-tag: noindex, nofollow
x-via: html
cf-cache-status: DYNAMIC
cf-request-id: 086c6c3cef00002d289a108000000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
strict-transport-security: max-age=15552000; includeSubDomains; preload
x-content-type-options: nosniff
server: cloudflare
cf-ray: 625a7ca7eba92d28-LHR
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

I only experienced this issue when ViaHTML was loaded inside an iframe, not when it was loaded in a top-level tab. Chrome and Firefox did not trigger the issue.

It looks like this particular frame came from an ad so it might not be reproducible if Wired changes their ads. Instead we might have to construct a test case which triggers the same effect.

Slack thread: https://hypothes-is.slack.com/archives/C1MA4E9B9/p1614014469019600?thread_ts=1614013943.019300&cid=C1MA4E9B9