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

101–110 of 118 posts

Re: Cache your CORS

#101

Post by tomjakubowski »

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.

> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.)

What is the benefit or purpose of doing this?

Re: Cache your CORS

#102

Post by tomjakubowski »

javier2 wrote: post #91
giancarlostoro wrote: post #65

Earlier quoted context omitted.

I feel like this is overkill when you have something like OPTIONS which is very minimalist in its response. Unless I'm missing some obvious drawback with calling OPTIONS?

Well, you double the latency for every. single. request.

CORS does not double latency for every single request. It adds the additional overhead of a separate OPTIONS request for every single request. Unless the responses are as trivial to compute/serve as OPTIONS responses are, that will be way less than a doubling in latency.

Re: Cache your CORS

#103

Post by icedchai »

tomjakubowski wrote: post #101
LunaSea wrote: post #61

Earlier quoted context omitted.

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.

> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) What is the benefit or purpose of doing this?

You don't have CORS configuration to worry about. It simplifies development and deployment.

Re: Cache your CORS

#104

Post by [deleted] »

icedchai wrote: post #103
tomjakubowski wrote: post #101

Earlier quoted context omitted.

> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) What is the benefit or purpose of doing this?

You don't have CORS configuration to worry about. It simplifies development and deployment.

[deleted]

Re: Cache your CORS

#105

Post by tomjakubowski »

icedchai wrote: post #103
tomjakubowski wrote: post #101

Earlier quoted context omitted.

> you want to serve your API from the same origin as your static files (HTML, CSS, JS, etc.) What is the benefit or purpose of doing this?

You don't have CORS configuration to worry about. It simplifies development and deployment.

You don't need to set up CORS to load assets on a page from a CDN's origin. Cross-origin taint only matters when trying to read asset data from a script.

I think we may be talking past each other and one of us is misunderstanding OP.

Re: Cache your CORS

#106

Post by icedchai »

tomjakubowski wrote: post #105
icedchai wrote: post #103

Earlier quoted context omitted.

You don't have CORS configuration to worry about. It simplifies development and deployment.

You don't need to set up CORS to load assets on a page from a CDN's origin. Cross-origin taint only matters when trying to read asset data from a script. I think we may be talking past each other and one of us is misunderstanding OP.

Yes, but you need it if your API isn't on the same origin as your static assets.

Re: Cache your CORS

#107

Post by moring »

djsweet wrote: post #69
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…

I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite... . This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple,…

Thanks a lot, I'll have a look into this.

Re: Cache your CORS

#108

Post by moring »

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…

> on the web server level

Does that mean that I'd have to introduce a web server in front of Firebase Hosting that I'd have to maintain and scale, not to mention that it negates all advantages of using FB hosting in the first place?

I'll stick with CORS, thank you.

Re: Cache your CORS

#109

Post by zmxz »

moring wrote: post #108
zmxz wrote: post #74

Earlier quoted context omitted.

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…

> on the web server level Does that mean that I'd have to introduce a web server in front of Firebase Hosting that I'd have to maintain and scale, not to mention that it negates all advantages of using FB hosting in the first place? I'll stick with CORS, thank you.

You're jumping to conclusion too fast. You already have the web server and you can already achieve no-CORS without "introducing" anything new. I'm not trying to convince you, but since you're someone who works in this field - you're drawing wrong conclusions. Stick to what you know, sooner or later you'll realize that CORS is not as simple and as benign as it may seem.

There's a comment below mine that tells you you can achieve this kind of proxy with the actual Firebase itself. And your comment, again, proves my hypothesis - people just make reasons up with improper arguments.

Re: Cache your CORS

#110

Post by zmxz »

0x457 wrote: post #96
zmxz wrote: post #74

Earlier quoted context omitted.

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…

Somehow, I think putting a proxy in front of Firebase is not the right solution here at all. The same goes when the website is served by any other CDN. Great, we have this thing that can serve nearly infinite number of requests has DDOS protection and is always close to the customer, let's put a proxy in front of it because we don't know how to setup CORS. CORS ain't that hard.

Why put anything in front of Firebase hosting? Why not use Firebase hosting as the front?

This confirms my initial comment - people making up reasons.

The solution is always the same, it's always as easy and there's never the need to introduce something new since you can use what you already have.

Post reply on HN