[philsnow]

Where do you queue those requests ? If you do it anywhere under your own control, you will accumulate memory and open connections.

If you issue a 429, the client knows it needs to wait and retry, and you've pushed the backpressure all the way past the demarcation line of your own infrastructure.

[daliwali]

One could limit concurrent connections per address. The idea is that an OPTIONS request which doesn't take much resources at all could be treated with a different weight than a POST which costs the server time to process.

[philsnow]

depending on the resources being thrown at you, just trying to limit concurrent connections per address could help (there's the question about how to keep information about how many connections a given address has opened distributed to your load balancing layer and consistent, or at least consistent enough to mostly do the right thing most of the time)

maybe that doesn't help with ipv6, though. you'd run out of memory if you tried to keep track of every /128, and different ISPs hand out different blocks to customers (some give out a /64, maybe some give each customer their own /72, etc).

> The idea is that an OPTIONS request which doesn't take much resources at all could be treated with a different weight than a POST which costs the server time to process.

I'm curious, what frameworks/libraries/whatever have you seen that use HTTP OPTIONS ?

[daliwali]

More sophisticated ways to reject connections rely on heuristics and may result in denying legitimate requests. I don't have all the answers, I'm just suggesting a way that doesn't consider all requests equal.

Every CORS pre-flight request uses the OPTIONS method. It is also used to advertise which methods are available on a route.

[philsnow]

> Every CORS pre-flight request uses the OPTIONS method.

https://stackoverflow.com/questions/8685678/cors-how-do-pref...

Neat, thanks :) didn't know that