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

61–70 of 118 posts

Re: Cache your CORS

#61

Post by LunaSea »

zmxz wrote: post #55
LunaSea wrote: post #41

Earlier quoted context omitted.

If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.

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.

Re: Cache your CORS

#62

Post by snowwrestler »

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.

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

Re: Cache your CORS

#63

Post by colinclerk »

> In practice, almost all cross-origin API requests will require these preflight requests, notably including

At Clerk, we took the opposite approach, and restructured our API so it fits within the narrow window that does not require a preflight

I wrote a little about it here: https://clerk.dev/blog/skip-cors-options-preflight

Re: Cache your CORS

#64

Post by giancarlostoro »

cakoose wrote: post #8

Unfortunately this caching is still per-path. For example: GET /v1/document/{document-id}/comments/{comment-id} For every new document-id or comment-id, there will be a new pre-flight request. Alternative hacks: Offer a variant of your API format that either 1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redacti…

> Conforms to the rules of a CORS "simple" request [1], which won't trigger a pre-flight request.

I was about to ask if OPTIONS would be sufficient, but it looks like some of the MDN URLs suggest just that.

Re: Cache your CORS

#65

Post by giancarlostoro »

Cthulhu_ wrote: post #33
cakoose wrote: post #8

Unfortunately this caching is still per-path. For example: GET /v1/document/{document-id}/comments/{comment-id} For every new document-id or comment-id, there will be a new pre-flight request. Alternative hacks: Offer a variant of your API format that either 1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redacti…

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.

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?

Re: Cache your CORS

#66

Post by LunaSea »

snowwrestler wrote: post #62
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.

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.

Re: Cache your CORS

#67

Post by LunaSea »

tylerhou wrote: post #46
LunaSea wrote: post #41

Earlier quoted context omitted.

If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.

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

Re: Cache your CORS

#68

Post by zmxz »

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.

Serving said JS on CDN implies that the JS performs xhr/fetch, which means I have control over said CDN

Given the fact I have control over domain(s), I'd have http://domain.tld/api for API and serve static js from http://domain.tld/static/*.js

Given the fact I have the need for CDN, it means I've got enough traffic that justifies the bill incurred

Re: Cache your CORS

#69

Post by djsweet »

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…

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, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.

Re: Cache your CORS

#70

Post by icedchai »

Cthulhu_ wrote: post #33
cakoose wrote: post #8

Unfortunately this caching is still per-path. For example: GET /v1/document/{document-id}/comments/{comment-id} For every new document-id or comment-id, there will be a new pre-flight request. Alternative hacks: Offer a variant of your API format that either 1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redacti…

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.

Yes, CORS is best avoided when your own back end is the "third party." (In some cases, it may be impossible though.)
Post reply on HN