[justin_oaks]

I'm hoping we as a community can learn from the major mistakes of NGINX configuration.

In general, if the users consistently make the same mistakes when using your software, then it's your (the software developer's) mistake, not the users. No amount of documentation will make up for poor design.

In the case of NGINX's "if", it goes contrary to people's mental model of how "if" should work.

Another failure in NGINX is the way array directives inherit from higher contexts (search for "array directive" in [1]). If you have add_header directives at one context and then lower contexts (i.e. location) will inherit all the add_header directives UNLESS another add_header directive is in the lower context. In that case, NONE of the previous add_header directives are inherited. This is completely contrary to the directive name "add_header" which implies adding a header, not wiping out all previous headers.

[1] https://blog.martinfjordvald.com/understanding-the-nginx-con...

[ris]

I think the fundamental mistake of nginx's configuration syntax was always making it look much more flexible and general than it actually is. Particularly with statements like `if` almost giving it the flavour of a general purpose programming language.

If you actually do try and make use of the apparent flexibility of the syntax, you very quickly start to run into situations where you inexplicably just "can't do that", with the failure mode frequently just being nginx quietly not doing the right thing.

[justin_oaks]

And quietly doing the wrong thing is a serious problem for software used to interact with the general public (i.e. public websites)

A single misconfiguration can be a major security issue.