Ok. To exploit any vulnerability the attacker have to do something. It's just obvious. I don't understand what you're trying to make clear.
> and attacker handcraft an http request packet, bypassing encode and sanity checking which is required in most HTTP client implementations
Well, it's not something hard to do. You don't have to dwell on this. To talk HTTP you don't even need HTTP client (sic!). Telnet or netcat can be easily used instead. I usually use them while configuring web-servers, most admins and devs usually do so.
A few quotes from the link, if you didn't read:
"Some checks on a request URI were not executed on a character following an unescaped space character (which is invalid per HTTP protocol, but allowed for compatibility reasons since nginx 0.8.41)."
[..]
"by requesting a file as "/foo /../protected/file" (in case of static files, only if there is a "foo " directory with a trailing space)"
"send_timeout 2;"
Mobile clients from another continent will "thank you" for this setting when they cannot open your site.
"error_log /var/log/nginx/error.log crit;"
A way to be unaware when something is wrong with your server. Nginx produces not only "crit" errors, but a bunch of very useful warnings, that need attention.
"limit_conn addr 10;"
Chrome and Firefox usually open more than 10 connections. And btw, have you ever heard about NAT?
"Most browsers will open up 2 connections"
15 years ago this was true.
What purpose of the article if in the documentation at nginx.org/en/docs/ you can find the same?
And, btw, you are giving bad advices. You are wrong here:
"By default, nginx sets our keep-alive timeout to 75s (in this config, we drop it down to 10s), which means, without changing the default, we can handle ~14 connections per second. Our config will allow us to handle ~102 users per second."
No, the keepalive connections doesn't limit nginx anyhow. Nginx closes keepalive connections when it reaches connection limit.
"gzip_comp_level sets the compression level on our data. These levesls can be anywhere from 1-9, 9 being the slowest but most compressed. We’ll set it to 6, which is a good middle ground."
No, it's not "middle ground". It kill performance of your server. With 6 you will get 5-10% better compression, but twice slowness.
"use epoll;"
What's the purpose of this? The docs says: "There is normally no need to specify it explicitly, because nginx will by default use the most efficient method."
"multi_accept tells nginx to accept as many connections as possible after getting a notification about a new connection. If worker_connections is set too low, you may end up flooding your worker connections. "
No, you have completely misunderstood this directive. It isn't related to worker_connections at all.