undefined | Better HN

0 pointsbzbarsky4y ago0 comments

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.

0 comments

3 comments · 2 top-level

jrochkind14y ago· 1 in thread

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

bzbarskyOP4y ago

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

thaumasiotes4y ago

True, 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.

j / k navigate · click thread line to collapse