Most L7 flood tools speak HTTP/1.1. The reason is simple: HTTP/2 needs a state machine, HPACK header compression and ALPN negotiation. Implementing that correctly is real work for someone writing an attack tool. HTTP/1.1 is plain text — open a socket, write a few lines.
That suggests a tempting idea on the defence side: if attackers speak HTTP/1.1, let's block HTTP/1.1.
Why the idea is only half right
Because attackers are not the only ones speaking HTTP/1.1:
- Older mobile browsers and some in-app browsers
- Users behind corporate proxies that do not terminate HTTP/2
- Payment provider webhooks and monitoring services
- Integrations written with curl
Turn the switch on and all of them get 426 Upgrade Required. And this is where the real problem starts: browsers do nothing with a 426. The spec says the client should upgrade, but no browser retries a GET over HTTP/2 because of that response. What the user sees is a blank error page.
A customer reported exactly this: "when an attack comes the firewall returns 426 for some reason". They had turned the switch on themselves to stop the attack — and were throwing their real visitors off the site at the same time.
The right answer: verify, don't block
HTTP/1.1 is not a crime, it is a signal. The right response to a signal is not to shut the door but to ask for identification.
In HexShield this switch no longer rejects HTTP/1.1 requests; it sends them to verification:
- A real browser solves the proof-of-work in under a second, gets the clearance cookie and browses happily over HTTP/1.1 afterwards.
- A typical flood tool cannot, so it does not reach the origin.
The switch keeps its benefit of narrowing the attack surface and loses the damage it did to real visitors. A 426 now appears in exactly one case: you turned verification off entirely. Then there is no soft path and the switch means only its old hard behaviour.
Pipelining is a separate matter
The genuinely dangerous side of HTTP/1.1 is pipelining: pushing dozens of requests down one connection without waiting for replies. That is the technique behind the Meris botnet's record-breaking attacks.
Detection counts per connection — because normally one connection means one visitor. But if your site sits behind a CDN that assumption collapses: the CDN carries hundreds of visitors down a single persistent connection, and 100+ requests per second on it is entirely normal.
So pipelining detection switches itself off when a CDN provider is selected in the panel. Knowing when a defence should turn off matters as much as knowing when to turn it on.