Hacker News Reader

Comment by panarky | Hacker News Reader

>> Typically this is possible. Images aren't subject to CORS.

> You're right, that was a misleading example. I changed it to data.json to be more clear.

CORS doesn't preflight GET, POST or HEAD methods unless they have custom headers or content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain.

So a simple GET bar.com/data.json works just fine in today's browsers.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

View on HN

In the absence of CORS header configuration on the target site, you can't use XHR or Fetch to get anything from a different domain. It doesn't matter if it's JSON, an image, or plain text.

To some extent, you're conflating some of the requirements to avoid preflighting with cross-origin requests simply being allowed, and they're not the same.

I'd be happy to be corrected on this, but here's what I understand:

While fetch doesn't preflight for GET, it does require an Access-Control-Allow-Origin header. You can specify `no-cors` in the mode to circumvent this, but then you cant access the response body (https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...)

Here's an example using your own site.

Open the console in an empty Chrome window and paste this:

  fetch('https://pfrazee.hashbase.io/feed.xml')
    .then(response => response.text())
    .then(str => console.log(str))

You'll get your RSS feed, no CORS tricks required.

My site has the Access-Control-Allow-Origin:* header set. Try the same thing on the Beaker site in the devtools for https://example.com.

    fetch('https://beakerbrowser.com/dat.json')
      .then(response => response.text())
      .then(str => console.log(str))

It should fail

It is failing for me because of the content security policy, which is a different thing.

That's the case on HN. Example.com doesnt have CSPs setup so it's CORS that causes the issue.

or content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain.

application/json is a content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain, and thus a request for it will fail unless the required CORS headers are present

There's a couple issues with your comment: first, the restriction you're talking about is related to preflighting, not to whether requests are allowed at all.

Additionally, you're thinking about the "wrong" Content-type header: the limitation you're mentioning about urlencoded and so on is a limitation on request headers, not response headers.

The CORS headers are required for the GP's described request to succeed, but not for the reasons you give.

Reply on news.ycombinator.com