HTTP/2 200
date: Tue, 02 Mar 2021 15:11:53 GMT
content-type: application/json
content-length: 2
access-control-allow-origin: *
via: 1.1 google
alt-svc: clear
strict-transport-security: max-age=15724800; includeSubDomains
expect-ct: max-age=86400, enforce
referrer-policy: no-referrer
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-frame-options: DENY
When browsing from Chrome, we are noticing a CORB message:
According to my understanding, this mecanism triggers because of the presence of X-Content-Type-Options header and because the browser assessed that there is some mismatch between the MIME type being adverdised application/json and the content {}.
The documentation mentions:
Because the JSON syntax is derived from and overlaps with JavaScript, care must be taken to handle the possibility of JavaScript/JSON polyglots. CORB handles the following cases for JSON:
[...]
Other JSON literals: The remaining subset of the JSON syntax (for example, null or [1, 2, "3"]) also happens to be valid JavaScript syntax. In particular, when evaluated as script, they are value expressions that should have no side effects. Thus, if they can be detected, they can be CORB- protected. Detection here is possible, but requires implementing a validator that understands the full JSON syntax:
[....]
If the response is indeed labeled with a JSON Content Type, CORB may decide to sniff the response to confirm it is valid JSON, only up to a certain number of bytes. This would avoid buffering and parsing in an unbounded amount of memory.
I don't quite understand why this protection fires up as the content seems to be a valid JSON document and matches the MIME type being advertised. Am I missing something?
Hello @dud225,
I am not so familiar with this mechanism but if it blocks the response of the request, it should not impact the data collection since we don't use the response.
Did you notice any unexpected behaviors except the warning?
If only the browser warning bother you, could you remove the culprit header from the response of your proxy?
No I didn't.
If only the browser warning bother you, could you remove the culprit header from the response of your proxy?
Yes I could but this header has some benefit, so that's not the option I was considering.
I'm closing this issue since the problem seems more related to Chrome.
@bcaudan I have the same issue but I'm not using a proxy. If the response is not used could it just return nothing? Because it seems like an empty object is not valid JSON according to Chrome...
@dud225 could you reopen
Hello @vdhpieter,
If you don't use a proxy or the mentioned header, your may face another chrome issue when the response is not empty:
https://bugs.chromium.org/p/chromium/issues/detail?id=1255707&q=corb%20sendbeacon&can=2
Could you check if this the case that you encounter?
Just updated @datadog/browser-rum from 3.2.0 to 4.6.1 in a project I'm working on and am now seeing the CORB warning dud225 screenshotted.
Not sure if this causes any actual problems, but wanted to report as it suggests the CORB warning may be caused by a change in @datadog/browser-rum.
Please refer to the documentation
Is there a plan to update the datadog js client so this warning isn't produced? Like @dud225 mentioned, the mismatch between the MIME type and reality is causing Chrome to block the response.
It's not a great developer experience with all the warnings produced.
