CORB OPTIONS Requests Blocked in Chrome 73

Question

It appears that in a recent Chrome release, (or at least recently when making calls to my API --- haven't see it until today), Google is throwing warnings about CORB requests being blocked.

Cross-Origin Read Blocking (CORB) blocked cross-origin response [domain] with MIME type text/plain. See https://www.chromestatus.com/feature/5629709824032768 for more details.

I have determined that the requests to my API are succeeding, and that it's the pre-flight OPTIONS request that is triggering the warning in console.

The application which is calling the API, is not explicitly making the OPTIONS request, rather I have come to understand this is enforced by the browser when making a cross-origin request and is done automatically by the browser.

I can confirm that the OPTIONS request response does not have a mime-type defined. However, I am a little confused as it is my understanding that an OPTIONS response, is only headers, and does not contain a body. I do not understand why such a request would require a mime-type to be defined.

Moreover, the console warning says the request was blocked; yet the various POST and GET requests, are succeeding. So it looks as though the OPTIONS request isn't actually being blocked?

This is a three-part question:

1. Why does an OPTIONS request require a mime-type to be defined, when there is no body response?
2. What should the mime-type be for an OPTIONS request, if plain/text is not appropriate? Would I assume application/json to be correct?
3. How do I configure my Apache2 server to include a mime-type for all pre-flight OPTIONS requests?

Answer 1

I have gotten to the bottom of these CORB warnings.

The issue is related, in part, to my use of the content-type-options: nosniff header. I set this header in order to stop the browser from trying to sniff the content-type itself, thereby removing mime-type trickery, namely with user-uploaded files, as an attack vector.

The other part of this, is related to the content-type being returned application/json;charset=utf-8. Per Google's documentation, it notes:

A response served with a "X-Content-Type-Options: nosniff" response header and an incorrect "Content-Type" response header, may be blocked.

Based on this, I set out to double check IANA's site on acceptable media types. To my surprise, I discovered that no charset parameter was ever actually defined in any RFC for the application/json type, and further notes:

No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.

Based on this, I removed the charset from the content-type: application/json and can confirm the CORB warnings stopped in Chrome.

In conclusion, it would appear that per a recent Chrome release, Google has opted to start treating the mime-type more strictly than it has in the past.

Lastly, as a side note, the reason all of our application requests still succeeds, is because it appears Cross-Origin Read Blocking isnt actually enforced in Chrome:

In most cases, the blocked response should not affect the web page's behavior and the CORB error message can be safely ignored.