12 ms·
The thing XHR added was: 1) POST. 2) Of arbitrary content. 3) With an arbitrary Content-Type header. You don't get an OPTIONS for the sort of XHR request th
by bzbarsky 5y ago
The thing XHR added was:
1) POST.
2) Of arbitrary content.
3) With an arbitrary Content-Type header.
You don't get an OPTIONS for the sort of XHR request that you could do with an <img> tag (always GET). You don't get an OPTIONS for the sort of XHR request that you could do with a <form> tag (GET or POST). You only get OPTIONS if one of the following is true:
* Your request method is not GET/HEAD/POST
* You set a header value for a header other than Accept, Accept-Language, Content-Language, or Content-Type.
* You set Content-Type to a value other than "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain".
* You have upload listeners on the XHR upload.
* You use ReadableStream in the request.
- thaumasiotes 5y agoTrue, though POST requests claiming to send form data are among the most threatening requests (and still would be if they weren't immune to CORS). It's a weird hole from a security perspective, though as you note it makes perfect sense from a historical-development perspective.
- jrochkind1 5y agoAlso 4) ability to see the text results of your request. No way for JS to do that with an IMG tag, I don't think.
- bzbarsky 5y agoIf the XHR is same-origin then you control that text anyway, so know what it is (and there is no OPTIONS anything going on), and if it's cross-origin then the text results are not exposed by default (unless the server jumps through the other CORS hoops to expose them). The OPTIONS bits are not relevant to this part.