Sorry I am not an expert, but just wanted to raise that I recall that in our firm we had to disable CORS caching a while back, as this was non compliant with some security standards. I think it had to do with this: https://vulncat.fortify.com/en/detail?id=desc.dynamic.html.h...
Cache your CORS
11–20 of 118 posts
Re: Cache your CORS
#12Very good and important advice, would advise caution when implementing this though - consider a shorter period when you make changes to CORS headers so that if you make a mistake you don't accidentally cut off your frontend for 24 hrs. I guess you could hack your way around it in an emergency but it'd still be painful.
The article mentions that Chrome max value is 7200 seconds (2h) but FF is 24h. In practice for our app we rolled out with 600 to make sure things were working. And now we run at 28800 (6h) (but 2h on Chrome)
Oh yeah I did observe that but couldn't bother making the distinction. In my head, that's the worst case for a decent portion of users (2-5% depending on where your users predominantly live and other demographics) so I consider that to be a 24 hr outage.
Your approach definitely sounds sane, would encourage others to do the same rather than following the article from the get go.
Re: Cache your CORS
#13I 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 pretty great. We have a number of applications that have different API and frontend origins, and it's frustrating to see that every request needs another roundtrip.
So I started thinking about how we did things pre-CORS and I've been wanting to build this frame-proxy in our API. Pretty helpful!
Re: Cache your CORS
#14Very good and important advice, would advise caution when implementing this though - consider a shorter period when you make changes to CORS headers so that if you make a mistake you don't accidentally cut off your frontend for 24 hrs. I guess you could hack your way around it in an emergency but it'd still be painful.
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.
Re: Cache your CORS
#15Wow, thank you, never heard about this before. I really hope this is not entirely correct but I will check our sites for sure. If options requests often bypass the edge servers some of the services we use are way better than expected.
Re: Cache your CORS
#16Sorry I am not an expert, but just wanted to raise that I recall that in our firm we had to disable CORS caching a while back, as this was non compliant with some security standards. I think it had to do with this: https://vulncat.fortify.com/en/detail?id=desc.dynamic.html.h...
The article you mention targets prolonged caching, which it defines as more than 30 minutes. Disabling might not have been necessary?
Re: Cache your CORS
#17Very good and important advice, would advise caution when implementing this though - consider a shorter period when you make changes to CORS headers so that if you make a mistake you don't accidentally cut off your frontend for 24 hrs. I guess you could hack your way around it in an emergency but it'd still be painful.
Just like DNS!
Absolutely. The SOA record is important too, to cover queries not taking the happy path.
However, once I comform that everything is working alright, I crank up TTL to one day to reap some performance gains. For sites with low visits, and likely to not have the DNS query cached, the query latency can add up, and sometimes goes as high as 100ms if the recursive resolver has to take several round-trips to resolve the whole domain chain at EDNS level.
Re: Cache your CORS
#18Excellent 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?
Re: Cache your CORS
#19CORS = 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.
Re: Cache your CORS
#20We just use a path prefix and a reverse proxy to save the pre-flight request altogether.