Re: [beacon] CORS and Credentials questions.

On 1/8/14 1:20 PM, Ilya Grigorik wrote:
> It'd be nice if we can avoid preflights. Out of curiosity, why is
> "text/plain" considered "safe" whereas "text/xml" is not?

Because you can produce a text/plain POST with an HTML <form> element, 
but you can't produce a text/xml POST that way.

Therefore, servers created before cross-site XMLHttpRequest POST was 
allowed had to handle the text/plain case no matter what to be secure, 
but they could assume that a text/xml POST was being done same-origin. 
Since we didn't want to create security holes when we started allowing 
cross-site XHR, we had to make sure we didn't just blindly perform a 
POST with the "text/xml" MIME type.

> Seems completely arbitrary,

It's not, unfortunately.

> and in practice why would I just not mark my XML
> payloads as text/plain to avoid extra roundtrip?

That's fine if you want to do that.  It means your POST then can't be 
used to attack the server, which is what the preflight is designed to 
protect against.

> Beacon in particular is a bit peculiar in that we don't expect to read
> the response, it's just a one way ping...

Yes, but the preflight isn't meant to guard against reading the 
response.  That's handled for old non-CORS-aware servers by the server 
simply not returning CORS headers, which means the browser doesn't let 
the script have access to the response.  The purpose of the preflight is 
to prevent a non-CORS-aware server from taking actions in response to a 
cross-origin request that the server didn't expect, and that constraint 
applies just as much to beacon as it does to XHR.

I'm not saying this is a great situation; no one thinks it is.  If you 
have a proposal that addresses the security concerns here, I'd love to 
hear it...

-Boris

Received on Wednesday, 8 January 2014 18:29:45 UTC