TL;DR: HTTP/2 is internally concurrent, can handle multiple streams. It is possible in HTTP/2 to send a nasty request that looks like so:
- GET x1
- GET x2
- GET x3
- ...
- GET x100
- Actually, cancel all of the above (uses multiple RST_STREAM frames)
- GET x101
- GET x102
- (...)
- GET x200
- Actually, cancel all of the above (uses multiple RST_STREAM frames)
- (...)
This can be repeated a lot of times. The problem is that the endpoint, which typically is a reverse proxy, might start dispatching the requests before it reads about their cancellation. And sure it will cancel them, but by the time of cancellation it will already have resulted in some resource usage downstream. Such requests are accepted because at no point the client has opened more than 100 streams, which is the typical concurrency limit. The example from the blog manages to squeze in a single packet 1000 GETs (i.e. 1000 HEADERS) correctly interleaved with RST_STREAM.
Maybe it's just me, but it's always fun to see such creative and simple abuses of protocols/code.
That’s pretty fascinating. This is a naive solution, but couldn’t the protocol have supported limits of requests per packet? I get that it is antithetical, but for most sites, this type of request pattern seems highly unusual.
If this is true than the design is problematic. What makes it even worse is that cancellation of requests typically does not work in cloud environments. It is a bit laughable that Azure for instance recommend the use of cancellation tokens but in reality you never get them for web requests.