Default content-type header interacts badly with new Chrome ORB feature

[sanason]

HTTP status 304 responses returned by our cloud.gov-hosted application are not loading correctly in Chrome.

Notes

Steps to reproduce (Chrome Version 125.0.6422.142 (Official Build) (arm64))

1. Visit https://touchpoints.digital.gov/. Note that there is a blue button at the bottom of the screen that says "How can we improve Touchpoints?".
2. Reload the page. Note that the button is gone.
3. Look in the Network tab (with "Disable cache" turned off). You should see a request to https://touchpoints.app.cloud.gov/touchpoints/92b47c29/js with status "(failed)net::ERR_BLOCKED_BY_ORB".

My theory of what's going on

In the Touchpoints code

Touchpoints is a Rack app and the Rack code deliberately deletes the Content-Type header for 304 responses.

In the cloud.gov code

Touchpoints is deployed on cloud.gov. I don't know much about the internals of cloud.gov but I'm guessing that the proxy defined in this repo is sitting in front of the Touchpoints app and is adding a default content-type header to our 304 response.

In Chrome

Chrome recently introduced a new security feature https://chromestatus.com/feature/5166834424217600. On the feature page, it is listed as "In development" but I'm pretty sure it has actually been deployed and fully rolled out. The new feature is not very well documented IMO but the spec has this line - "If nosniff is true and mimeType's essence is 'text/plain', then return false" - which I think explains where the net::ERR_BLOCKED_BY_ORB error is coming from.

Acceptance Criteria

• cloud.gov-hosted applications should be able to return 304 responses without content-type headers and still work in Chrome.

I may be biased but I think Touchpoints's behavior is above board here. The HTTP spec recommends limiting headers returned for 304 responses.

I defer to the cloud.gov team as to whether or not this is a Chrome bug vs. something that could be fixed in cloud.gov.

[sanason]

Brian asked me a reasonable question:

Have you noticed this behavior elsewhere or is it observed specifically with Touchpoints?

No, I haven't. It requires a pretty specific set of circumstances to reproduce and I don’t know enough about what is deployed on cloud.gov to have an idea of where these circumstances might be replicated. I would need to find:

1. A page that makes a cross-origin request to a resource hosted on cloud.gov, where
2. (Probably) the request is for dynamic content (since it returns HTTP status 304 rather than being fulfilled immediately from the cache), and
3. The request is not a script-initiated request (because Chrome hasn’t implemented ORB for these requests yet, though they say that they plan to, see Intent to Ship).

[sanason]

My proposal is that this proxy not add default Content-Type headers to empty-body responses, or (more limited) not add them to responses with status codes that don't permit bodies (204, 304), or (even more limited and all we really need on Touchpoints) just not add them to 304 responses.

[markdboyd]

After deploying #86 to production, I cannot reproduce the original behavior. @sanason has confirmed separately that the fix is working. This ticket can be closed.