21–30 of 118 posts
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?
For example, to allow abc.com AND bcd.com, you could check Origin and if correct return Access-Control-Allow-Origin: *. In this case, setting Access-Control-Max-Age will mean this applies to any site* after a single successful request. If you return the site's name, this will break CORS* for that amount of time if an attacker makes a single request to it.
We just use a path prefix and a reverse proxy to save the pre-flight request altogether.
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…
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…
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.
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.
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…
GraphQL
ducks
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…
> Offer a variant of your API format that either: 1. Moves the resource path to the request body GraphQL ducks
And now you have two problems
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?