w3c / beacon

Beacon
https://w3c.github.io/beacon/
Other
46 stars 22 forks source link

cleanup processing section #54

Closed igrigorik closed 6 years ago

igrigorik commented 6 years ago

Closes #53.


Preview | Diff

igrigorik commented 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?

tyoshino commented 6 years ago

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).

annevk commented 6 years ago

That matches my analysis of the situation.

igrigorik commented 6 years ago

Ditto. Merging, thanks all!