Clarify the way CORB should be applied to beacons

[FarSeeing]

According to specification beacon request mode is determined by Content-Type: if it's specified and value is CORS-safelisted - then mode should be cors, otherwise (default case) - no-cors.

CORB specification does not state if beacon requests should be blocked but mentions that it's a helping mechanism where CORS cannot be applied. This leads to idea that when beacon request mode is set to cors request should not be blocked.

So it means that response should be treated based on request data's type and that makes no sense for me. Moreover, that means server is not able to turn off CORB unless client sets correct Content-Type (and it shouldn't be CORS-safelisted).

What about adding more controls or maybe disabling CORB for beacon requests at all (since the response cannot be used anyway)?

[annevk]

Can you elaborate on what problem you are having?

[FarSeeing]

We have 2 domains - site.xyz sending tracking data to cool-analytics.xyz with beacon requests. We also send debug data in response, simple JSON object like {"id": 123}. Now this becomes unreadable in latest Chrome because

• we cannot send application/json or any other non-CORS-safelisted mimetype since Chrome doesn't support that (and that's a known bug)
• since we're using "default" mimetype CORB blocks the response data.

Sure thing it needs fixing in Chrome/Chromium but at least CORB part is done by spec.

[annevk]

This part of CORB (which would rely on sniffing) isn't specified yet, see whatwg/mimesniff#87. But even if it were, I don't think we'd disable it because of implementation issues as that would weaken security guarantees and could lead to security issues. So I suggest taking this up with Chromium directly.

[FarSeeing]

What about adding header (Cross-Origin-Resource-Policy maybe) that will explicitly states that this particular request/location should not be CORB-blocked?

[annevk]

That's what CORS is.

[FarSeeing]

Could you explain that please? What header(s) should I set to disable CORB? Here I see a reference to X-Content-Type-Options only.

[annevk]

If you opt into CORS with sendBeacon() you won't have an issue with CORB.

[FarSeeing]

That's exact;y why I created this issue - there's no way of controlling CORS/CORB on server for beacon, With fetch I can manually set mode: 'cors', with beacon I need to set Content-Type and if it will be say text/plain - CORS cannot be enabled at all.

[annevk]

In that case use fetch() with keepalive, which should be equivalent and is the newer way of doing things.

[rodiwa]

AFAIK, fetch() + keepalive also has its restrictions. fetch() + keepalive is sometimes disallowed if a preflight request has to be made for your request. Basically if your request has any non-CORS friendly request headers in them, a preflight request (OPTIONS) will first be made. If this happens, the browser can throw an error that says "Preflight request for request with keepalive specified is currently not supported".

But if your request headers is CORS friendly, then a preflight will not be made and fetch() + keepalive should work just fine.

[annevk]

That sounds like a browser bug. Please file it against the relevant browser if you continue to see that! I'm going to close this as there doesn't seem to be a problem with the Fetch Standard here.