Closed igrigorik closed 6 years ago
@tyoshino updated, ptal. I don't think we need the extra otherwise, we can just move the "cors" inside the if content-type block. Does that look good?
Thank you, Ilya. After writing the last comment, I wondered if I'm still missing something from the discussion you all made previously. I'll summarize my thoughts here so that we can confirm that everyone's on the same page.
As discussed in https://github.com/w3c/beacon/issues/32#issuecomment-229083217, to ease migration from the image ping approach, we considered relaxing the CORS requirements, and we concluded turning off the CORS check perspective of the CORS algorithm for sendBeacon() is acceptable, while turning off the CORS preflight is not.
So, we need to make it perform the CORS preflight when needed. The only way for sendBeacon() to be subject to it is when to add a Content-Type with non-CORS-safelisted value. So, when we don't add any Content-Type header, it's not subject to the requirement.
When fetch() is used with the no-cors mode and the POST method but without the Content-Type header (even if we try to add it, request-no-cors
guard prevents it though), we can already do the same (without keepalive though).
That matches my analysis of the situation.
Ditto. Merging, thanks all!
Closes #53.
Preview | Diff