Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cache your CORS

httptoolkit.tech

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Cache your CORS

#71

Post by chrisweekly »

LunaSea wrote: post #61
zmxz wrote: post #55

Earlier quoted context omitted.

Can you provide an example, just so we can be on the same page? You do an XmlHttpRequest or fetch() to a static asset and it's a non-trivial request to CDN, I just wonder how it looks like and why it exists in the first place.

Say that you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) but you also want said static files to be served by a CDN. Basically that won't work besides making your CDN somehow proxy requests for which not static file exists.

It's an extremely common scenario. The obvious and straightforward solution is to configure path-based cache rules exactly like you describe, to proxy requests which don't correspond to static assets. Cloudfront allows you to do this out of the box, as do other major CDN providers. If your CDN doesn't support this, consider switching - or introduce an edge proxy to facilitate it.

Re: Cache your CORS

#72

Post by icedchai »

zmxz wrote: post #35
Cthulhu_ wrote: post #33

Earlier quoted context omitted.

3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

Many devs (young or not, age doesn't matter) simply have no idea how CORS works and don't understand the "same origin" policy. I've seen hundreds of hours wasted on CORS / OPTIONs request implementations that could've been saved with a reverse proxy, if only they knew what one was.

Re: Cache your CORS

#74

Post by zmxz »

moring wrote: post #56
zmxz wrote: post #35

Earlier quoted context omitted.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens. I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest so…

There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains.

As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about problems related to cross origin resource sharing and because I know how to write the necessary configs. If you don't have to walk through mine field, you never worry about mines. That's the easy part I refer to. I don't even need to test whether CORS is set up properly, worry about preflight and what not etc. - it works, forever.

Whether it will be as easy for you, I can't tell that, you can have completely different opinion and be correct about it, but the fact remains that proxy between 2 resources removes the problem. I consider problem removed as something easy, you might not.

Re: Cache your CORS

#75

Post by remram »

ShinTakuya wrote: post #25
unwind wrote: post #19

CORS = Cross-Origin Resource Sharing. There, that wasn't so hard, was it? I assume this is written for web developers who find this the most familiar acronym in the world, but ... still, it would not kill anybody to include the definition of the acronym, perhaps even with a friendly link [1] to make it Even More Accessible. I'll be off looking at the lawn mowing robot, now. [1]: https://developer.mozilla.org/en-US/do…

In the web development world CORS is as common an acronym as REST or TCP. I sympathise with the endless need to look up acronyms but in my view anyone involved enough with web to need the above advice would (or should) know the acronym. I do appreciate your point of view, but inclusiveness shouldn't come at the cost of brevity when those who would be included wouldn't benefit from it.

If the domain wasn't literally called "httptoolkit" it would be hard to know that this article relates to the "web development world" at all. Though I do imagine most people on HN are part of that world.

Re: Cache your CORS

#76

Post by marcofatica »

pas wrote: post #53
danwee wrote: post #29

Earlier quoted context omitted.

> GraphQL And now you have two problems

But you have a nice schema for your problem :) GQL is a bit ugly, but works well, kind of standardized, etc. Is there something similar for providing a batch endpoint for OpenAPI requests?

  GET /blog/1?with=comments,author&only=title,body,created_at,comments.body,author.name

Re: Cache your CORS

#77

Post by zmxz »

LunaSea wrote: post #67
tylerhou wrote: post #46

Earlier quoted context omitted.

IIRC Cloudflare has page rules, which makes this possible? In fact, with page rules, Cloudflare can proxy a subpath (like /api) to a completely different domain.

As I mentioned above this doesn't work for all CDNs and also involves trusting your CDN to MitM your API

This kind of comment falls under what I posted originally - people making up reasons why they can't go with proxy solution.

Re: Cache your CORS

#78

Post by Quarrelsome »

zmxz wrote: post #74
moring wrote: post #56

Earlier quoted context omitted.

I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens. I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest so…

There's 1 way to solve this, and it's to have the same domain that the end client (browser, app) uses. It means you'd create 1 domain that's exposed to client and on the web server level you perform routing (proxying) to appropriate firebase/cloud run domains. As for whether that's easier - I've been doing it like this since forever, so I'm biased and it's easy for me. It's easy because I don't have to worry about pr…

It's would argue its all about just not throwing a bunch of buckets and rakes on the floor during the networking design-phase that your entire dev, qa and then dev ops teams will proceed to walk into in every other stage that follows.

If you're dealing with a bunch of separate black boxes (as our firebase poster is) then maybe you do have to wrangle CORS but if you're developing your own applications then there is no good reason to introduce these issues into your pipeline.

Re: Cache your CORS

#79

Post by LanceH »

icedchai wrote: post #72
zmxz wrote: post #35

Earlier quoted context omitted.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

Many devs (young or not, age doesn't matter) simply have no idea how CORS works and don't understand the "same origin" policy. I've seen hundreds of hours wasted on CORS / OPTIONs request implementations that could've been saved with a reverse proxy, if only they knew what one was.

CORS is one of my favorite interview questions (front-end/react dev) as it has the potential to tell me if the interviewee is the person who has researched the problem and implemented solutions. There is a lot of potential discussion from how it works, why it's necessary, to how it is solved in production vs development.

Re: Cache your CORS

#80

Post by snowwrestler »

LunaSea wrote: post #66
snowwrestler wrote: post #62

Earlier quoted context omitted.

We use Fastly (the Hosts feature) to do exactly this. Basically it routes requests to different backends based on the URL path. If it starts with /assets, the backend is S3. If it starts with /api, the backend is our application. If it starts with /blog, the backend is Wordpress. All on different hosting platforms. (In case it’s not clear, Fastly is also caching and serving these requests as a CDN.)

So that would indicate that you don't do end-to-end TLS on your infrastructure for the API which means that Fastly man-in-the-middles your API. In a lot of sensitive businesses that wouldn't be allowed.

Are you sure about that? Have you talked to a good lawyer about it?
Post reply on HN