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

81–90 of 118 posts

Re: Cache your CORS

#81

Post by dspillett »

ShinTakuya wrote: post #14
WirelessGigabit wrote: post #10

Earlier quoted context omitted.

Just like DNS!

Oh yeah, DNS can be very painful. Definitely been burnt in the past. I generally lower the TTL to 5 minutes a day or so ahead of making any changes just to reduce risk, but DNS is even worse given that not everyone even respects TTL.

I've taken to keeping my TTLs at 5 minutes as a default for personal stuff. The potential extra latency of a full update every time you access a not-very-often accessed resource is fine and even for commonly accessed things the performance difference is negligible. Though I'm away I'm putting a little extra load on DNS caches elsewhere as they need to make extra recursive queries, so I might not do that for a high traffic service.

> not everyone even respects TTL

This used to be a problem with at least one common DNS cache, where it would see a very small value as an error and apply its own default (24 hours IIRC) instead. 10 minutes was fine, but 9m59s and it would not update until next day (the threshold may not have been 10 mins, it could have been 500s (8m20s), but it was something of that order).

I'm pretty sure that is not longer a common DNS daemon, or if it is that behaviour has been fixed, so these days I'm not really concerned for my projects. For work things I might be a bit more restrained with short TTLs, just in case (for personal projects I can take the “it is not my fault your DNS setup is broken” line, but that sort of attitude doesn't always fly in a commercial environment!).

Re: Cache your CORS

#82

Post by [deleted] »

corentin88 wrote: post #18
harry1989 wrote: post #6

Excellent suggestion. These days chrome hides the preflight requests by default and you miss to notice the latency added for each of those CORS calls. Also we don't deal with CORS unless it's an external plugin that we include in our site. Earlier we had subdomains like api. .com, static. .com to parallelize network requests which required CORS to be setup. With H2 we got rid of all of them and load everything from a…

What’s H2?

[deleted]

Re: Cache your CORS

#83

Post by turblety »

emilsedgh wrote: post #9
bluepnume wrote: post #7

I built fetch-robot ( https://github.com/krakenjs/fetch-robot ) to avoid dealing with CORS preflight requests. And the associated maze of request and response headers you need to use to negotiate in the preflight.

This is actually a very clever hack. What are the gotchas?

It's 44kb. Although I'm sure it could be made much, much smaller.

Re: Cache your CORS

#84

Post by yencabulator »

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…

Yeah. For example, the Meilisearch search engine recommends submitting idempotent searches over POST and not GET due to this: https://docs.meilisearch.com/reference/api/search.html

I wish they'd standardize HTTP QUERY soon: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...

Re: Cache your CORS

#85

Post by stblack »

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…

Downvotes for a comment like this is really the low-side of Hacker News.

Me: web developer since 1996. I had to look it up. Came here to make the same comment, and see you being lambasted for it.

Don't let these haterz get you down. It's standard practice across ALL domains to define acronyms, and those who give this article a pass because ReASonS!! aren't people I'd willingly choose to work with: anglo-saxons who believe the whole world shares their lived experience, and their mental model.

Hacker news is just horrible for that attitude. Accessibility is a thing.

Re: Cache your CORS

#86

Post by stblack »

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.

Brevity? It's a 1,500+ word article.

Re: Cache your CORS

#87

Post by yonran »

This is a good practical article. One minor clarification:

> cross-origin API requests will require these preflight requests, notably including: … Any request including credentials

No, setting XMLHttpRequest’s withCredentials:true and fetch’s credentials:"include" to send the user’s Cookie with the request does not imply that a preflight request must be made, since and sent the Cookie with cross-site requests (back in the CSRF days when the default Cookie SameSite flag was effectively SameSite=None). Maybe he was referring to a custom header such as Authorization, which does trigger prefetch.

Re: Cache your CORS

#88

Post by [deleted] »

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.

[deleted]

Re: Cache your CORS

#89

Post by kevincox »

nmjenkins wrote: post #39
zemnmez wrote: post #22

Access-Control-Max-Age has, unfortunately a big security caveat which is that it is cached on a per-endpoint basis. Because Access-Control-Allow-Origin only allows one origin specification, if you previously used the Origin header to determine who could access the API, your next API requestor will effectively get your last response. For example, to allow abc.com AND bcd.com, you could check Origin and if correct retu…

This is because you have forgotten to return a `Vary: Origin` header in the response. If you don’t do this, caches will presume the response is the same regardless of the Origin header in the request and so you will get the bug you describe.

Of course note that some common CDNs just ignore the `Vary` header. cough Cloudflare cough. Also IIRC not refusing to cache anything with a `Vary` header but caching it anyways and serving it no matter what headers the client sends.

Re: Cache your CORS

#90

Post by javier2 »

LanceH wrote: post #79
icedchai wrote: post #72

Earlier quoted context omitted.

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.

CORS is something I 'fixed' once, five years ago. Hard to talk in detail about that anymore. I wish we would have the time to implement it safely, but alas. We still can't produce an allowList of allowed domains :/
Post reply on HN