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

31–40 of 118 posts

Re: Cache your CORS

#31

Post by Dangsuckslol »

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.

No post body was provided.

Re: Cache your CORS

#33

Post by Cthulhu_ »

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.

Re: Cache your CORS

#35

Post by zmxz »

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.

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.

Re: Cache your CORS

#36

Post by lbriner »

hugobauer wrote: post #32

Doesn't moving the API from the subdomain to the /api path on the same subdomain as the website solve the problem?

Yes but 1) You would need a proxy to redirect the /api path to another application and 2) The API could easily be hosted separately so you would send your request via the main origin server just for it to actually go somewhere else. 3) You are not necessarily talking about a private API for an app but a shared API for multiple domains in which case, this is not a solution.

Re: Cache your CORS

#37

Post by lbriner »

kareemsabri wrote: post #20

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

"just use"!

What if the API is shared between multiple domains? Do you need to reverse proxy it everywhere?

What if it is a public API for third-party sites?

Re: Cache your CORS

#38

Post by kareemsabri »

lbriner wrote: post #37
kareemsabri wrote: post #20

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

"just use"! What if the API is shared between multiple domains? Do you need to reverse proxy it everywhere? What if it is a public API for third-party sites?

Yes, just use. The fact that less common edge cases exist doesn't undermine the solution. The example in the article was example.com and api.example.com, the most common setup imo.

> What if the API is shared between multiple domains? Do you need to reverse proxy it everywhere?

It would depend on your specific setup. We use a single nginx server entry to proxy many domains.

> What if it is a public API for third-party sites?

Then this approach would not be viable.

Re: Cache your CORS

#39

Post by nmjenkins »

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.

Re: Cache your CORS

#40

Post by nmjenkins »

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…

> Moves the resource path to the request body

JMAP is very well suited to CORS due to this: https://www.rfc-editor.org/rfc/rfc8620.html

Post reply on HN