This x1000. So many of those are terrible default behavior. They admit as much when they say things like "doesn't work how you'd expect".

I get that NGINX is powerful. But I hate dealing with it. Every. Single. Time.

Nginx rose out of the cesspit that was Apache config files. For me it was night and day better and I love the fact Nginx is just set and forget.

That's not to say it can't improve...

The worst part is that these problems only manifest under high load. Unless a team does performance testing (for long periods of time? in a highly-production-like environment), they might never know of many of these issues.

Cynical view: a great way to sell consultancy services / their Plus product?

Less cynical view: the defaults are designed to work for a majority of use cases and the majority of nginx users aren't running high traffic servers.

It doesn't seem the high traffic settings would adversely affect low traffic instances, which is why these defaults smell so bad.

"Doesn't work how you'd expect" reminds me of the time that we had users receiving responses from other people's requests.

Why? Our API is idempotent, but we needed to use POST instead of GET to let the browser send a request body. Our API is very slow, so we put NGINX in front of our API to cache responses. We used something like proxy_cache_key "$request_uri|$request_body"; I don't think I was completely remiss in thinking that $request_body means "request body". Testing showed that it worked just fine. In production, some users made requests that were larger than our tests - and then $request_body is empty, and users will get each others' responses. This behavior is helpfully documented as follows:

"The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer."

Stackoverflow is more helpful: https://stackoverflow.com/questions/18795701/nginx-proxy-cac...

Alternatively the config can be versioned when a single directive at top is sufficient to have saner defaults.

This. I would love to be able to specify a profile in almost every kind of file. Start with, say,

  profile base2022

and upgrade the defaults yearly. Provide a page detaillibg the differences so users can review what they have to do to up their baseline. Existing users can upgrade at their own pace, new users start with the best possible configuration.

You could do this in a cooperative manner: produce it as a set of include files, put it on GitHub or whatever, and spread the word.

Yes, this is much better than a "normal vs. strict" directive in any conceivable way.

It also helps on slowly deprecating the older behavior, you just say "nginx2004 is now deprecated", and people understands what you mean.

Absolutely. If you (nginx) know how your product should be configured, you should configure it that way out of the box. Don’t blame users.

And if backward compatibility is important, take a leaf out of Rust’s book and make a nginx-config-version 2; directive or something.

With this set, you can safely use the new defaults. Use it across all example configurations on the website and in distribution packages.

It is interesting to see nginx commit the same mistakes that led Apache to its demise.

> However, maybe a release or two of deprecation or better optimized defaults under new names or a new (kinda gross but...) strict mode which is opt-in but is the new default for new instalations.

Something like this or a \version "2.12.0" command would be massively useful. The alternative is a sea of undisclosed footguns that are blindingly obvious once you know they exist but otherwise are well-camouflaged. Ok, the other alternative is for every future developer to brainlessly spam a long incantation of sensible values that they swear they'll learn about later just so a Fortune 500 early-adopter company can have smoother upgrades.

Ah, proxy_buffering. I like nginx but that setting always bites me.