Cache your CORS
httptoolkit.tech
Cache your CORS
1–10 of 118 posts
Re: Cache your CORS
#2Damn, I am kinda surprised we don't have this enabled on our site. Thanks for dropping this tonight.
Re: Cache your CORS
#3Very 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.
Re: Cache your CORS
#4Damn, I am kinda surprised we don't have this enabled on our site. Thanks for dropping this tonight.
A few years ago (last I looked), most big ecommerce sites missed this. Even ones that had invested quite a lot in the performance of their site.
Re: Cache your CORS
#5Very 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)
Re: Cache your CORS
#6Excellent 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 single domain. This reduced the CORS surface area.
Re: Cache your CORS
#7I 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.
Re: Cache your CORS
#8Unfortunately this caching is still per-path. For example:
GET /v1/document/{document-id}/comments/{comment-id}
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, redaction) might not be ok with this, e.g. do your WAF rules support matching on the request body? You also will no longer get automatic path-based caching for GET requests.
2. Conforms to the rules of a CORS "simple" request [1], which won't trigger a pre-flight request. This is what we did on the Dropbox API [2]. You'll need to move the auth information from the Authorization header to a query parameter or the body, which can be dangerous wrt redaction, e.g. many tools automatically redact the Authorization header but not query parameters.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...
[2] https://www.dropbox.com/developers/documentation/http/docume... (see "Browser-based JavaScript and CORS pre-flight requests")
Re: Cache your CORS
#9I 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?
Re: Cache your CORS
#10Very 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!