11–20 of 31 posts
Earlier quoted context omitted.
When making comments like this, it would be enormously helpful to quote the title as you saw it. The current title seems to match the source and I can't tell if it's already edited or if I'm missing something.
[flagged]
Is it just me or does it seem insane that they just casually mention a segfault being a known possible outcome for normal user input? I would think that any kind of segfault should be considered a severe bug that needs immediate attention. Am I missing something here?
> Anything else may possibly cause unpredictable behaviour, including potential SIGSEGV. Is it just me or does it seem insane that they just casually mention a segfault being a known possible outcome for normal user input? I would think that any kind of segfault should be considered a severe bug that needs immediate attention. Am I missing something here?
> Anything else may possibly cause unpredictable behaviour, including potential SIGSEGV. Is it just me or does it seem insane that they just casually mention a segfault being a known possible outcome for normal user input? I would think that any kind of segfault should be considered a severe bug that needs immediate attention. Am I missing something here?
One of the last paragraphs is illuminating as to why `if` is so weird in NGINX:
> Directive “if” is part of rewrite module which evaluates instructions imperatively. On the other hand, NGINX configuration in general is declarative. At some point due to users demand an attempt was made to enable some non-rewrite directives inside “if”, and this lead to situation we have now. It mostly works, but… see above.
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...
> Anything else may possibly cause unpredictable behaviour, including potential SIGSEGV. Is it just me or does it seem insane that they just casually mention a segfault being a known possible outcome for normal user input? I would think that any kind of segfault should be considered a severe bug that needs immediate attention. Am I missing something here?
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…
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.
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…
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 tha…
A single misconfiguration can be a major security issue.
> Anything else may possibly cause unpredictable behaviour, including potential SIGSEGV. Is it just me or does it seem insane that they just casually mention a segfault being a known possible outcome for normal user input? I would think that any kind of segfault should be considered a severe bug that needs immediate attention. Am I missing something here?
This entire article feels like blaming users for being confused by a confusing configuration language with unclear feedback.