HTTP/1.1 traffic on my server looks mostly automated, and modern browsers broadly support HTTP/2. Is there a good reason to keep HTTP/1.1 available, or is disabling it a reasonable way to reduce unwanted traffic?
Is there still a good reason to keep HTTP/1.1 enabled?
Asked by
TANGENT9
Answers
I wouldn’t turn it off just because the traffic looks bot-heavy. HTTP/1.1 is still used by some legitimate tools and older clients, and dropping it won’t stop bots that can use HTTP/2. Check which actual users or services depend on it before making the change.
Reply to this answer
One technical detail: HTTP/2 and HTTP/1.1 are distinct protocols. A client and server negotiate which one to use, and having HTTP/2 available does not automatically make an HTTP/1.1-only client work. If you disable HTTP/1.1, some command-line tools, monitoring checks, libraries, or intermediary systems may simply fail to connect. The impact depends on who calls your service, not just on what browsers support.
Reply to this answer
If the goal is reducing bots, removing HTTP/1.1 is a pretty blunt filter. Some automated clients will use HTTP/2 too, while some ordinary services still send HTTP/1.1. Rate limits, access rules, or challenges based on suspicious behavior are more targeted options than treating every request on one protocol as unwanted.
Reply to this answer
For a small service used only by current browsers, disabling HTTP/1.1 might be an acceptable choice if you’ve checked your logs and can tolerate the occasional compatibility issue. For a public site, API, or service used by other software, I’d keep it unless there’s a concrete reason to remove it. The useful question is whether any legitimate clients rely on it, not whether HTTP/2 is widely available.
Reply to this answer
Add your answer
Answers are reviewed before publication.
TANGENT9:
Would adding an extra check for HTTP/1.1 requests be a safer middle ground?
k0balt:
Maybe, but the protocol alone is a weak signal. A check could inconvenience a real client while a bot switches protocols, so I’d base restrictions more on request patterns and the endpoint.