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

41–50 of 118 posts

Re: Cache your CORS

#41

Post by LunaSea »

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.

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

It's a very common case.

Re: Cache your CORS

#42

Post by beebeepka »

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.

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

Re: Cache your CORS

#43

Post by three14 »

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…

To hijack the thread a bit, if you are still with Dropbox, could you get them to implement what you did in #2 in the official Dropbox JS SDK? Right now it still does a pre-flight request for everything.

Re: Cache your CORS

#44

Post by jeroenhd »

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.

Alternatively, stick to "simple requests". That's HEAD, GET, and POST, without any custom headers or non-form content-type set. This adds some further limitations (no ReadableStream being one of them). If the backend responds with an appropriate access-control-allow-origin then the request will just succeed.

Re: Cache your CORS

#45

Post by jeroenhd »

beebeepka wrote: post #42
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.

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

Running a proxy on localhost isn't very difficult; it requires maybe 10 or 20 lines of nginx config, less with Caddy? Certainly something that can be stuffed into the README for developers.

Re: Cache your CORS

#46

Post by tylerhou »

LunaSea wrote: post #41
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.

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.

Re: Cache your CORS

#47

Post by jeroenhd »

thr0wnawaytod4y wrote: post #23
kareemsabri wrote: post #20

We just use a path prefix and a reverse proxy to save the pre-flight request altogether.

Could have other sec consequences, e.g. XSS in the API is now all of a sudden exploitable, just an example

There are solutions for that; for example, it can also be avoided in prod by having a JS-specific subdomain that's the only domain whitelisted by the CSP, separate from the main API. HTTP/2 connection pools should be recycled and simple inclusions don't require CORS so I don't expect many downsides. As an added bonus, such a configuration would be easier to use in combination with a CDN.

Re: Cache your CORS

#48

Post by taberiand »

jeroenhd wrote: post #45
beebeepka wrote: post #42

Earlier quoted context omitted.

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

Running a proxy on localhost isn't very difficult; it requires maybe 10 or 20 lines of nginx config, less with Caddy? Certainly something that can be stuffed into the README for developers.

Or better yet, into the devcontainer

Re: Cache your CORS

#50

Post by quickthrower2 »

Dangsuckslol wrote: post #31
ShinTakuya wrote: post #25

Earlier quoted context omitted.

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.

Quoted post unavailable.

> They can't even spell rest.

Neither can you. It is REST.

Post reply on HN