6

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.

enter image description here

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?

enter image description here

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?
sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Crayons
  • 1,906
  • 1
  • 14
  • 35
  • The OPTIONS preflight is succeeding. If it were failing, the browser would stop right there and never move on trying your POST request. The fact that you see the POST request indicates that the preflight succeeded. The OPTIONS request doesn’t require a mime type to be defined. There’s no indication in the question that you have any CORS problem at all. Instead you have a CORB problem. The error message cited in the question indicates your code is getting a text/plain response but the code is trying to use that response in some context where the browser doesn’t expect text/plain to be used. – sideshowbarker Apr 12 '19 at 10:51
  • You can probably get better help here if you update the question to add a snippet of your frontend code that shows how you’re making the request and how you’re consuming the response. For example, you may be getting the CORB error because your code is trying to parse that text/plain response as JSON. – sideshowbarker Apr 12 '19 at 10:53
  • Correct, as I noted, the OPTIONS request is succeeding, because the POST request is succeeding. You are also correct, in that I too, did not think the OPTIONS request needed a mime type, yet Chrome seems to think it does? You are also correct that I do not have a CORS issue, my question is not about CORS, thus I don't bring it up. As you can see in the example POST response, I am returning the appropriate mime type -- the warning in Chrome, relates to the OPTIONS request, which does not have a mime-type (because I believe it doesnt need one). I am beginning to believe this is a bug in Chrome. – Crayons Apr 12 '19 at 17:27

2 Answers2

5

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.

Crayons
  • 1,906
  • 1
  • 14
  • 35
  • Exact same errors here. Did you include Content-Type: application/json in the response headers of OPTIONS requests ? I removed the charset from my responses, and I still got those warnings (my API doesn't provide a Content-Type header for OPTIONS requests) – gouy_e May 13 '19 at 11:23
  • 1
    In my tests using `application/json;charset=utf-8` versus using `application/json` as the content-type does not have any effect on the CORB warning message. The only way I have been able to remove the warning has been to stop returning the `content-type-options: nosniff` header for OPTIONS requests. – JanneK May 18 '19 at 08:40
  • 1
    I made a small test util available here: https://foobar.kytomaki.com/corb-test/. It makes a POST request to a PHP script. By default the script returns the `nosniff` header only for the POST request and you shouldn't see any warnings. By checking the first checkbox the header is also returned for the OPTIONS request and you should see the CORB warning appear. The second checkbox controls whether the charset will be appended to the end of the content-type, and for me it doesn't seem to make any difference. – JanneK May 18 '19 at 08:41
0

Was having the same issue.

The problem I had was due to the fact the API was answering to the preflight with 200 OK but was an empty response without the Content-Length header set.

So, either changing the preflight response status to 204 No Content or by simply setting the Content-Length: 0 header solved the issue.

André Mota
  • 96
  • 5