5 ms·

If is Evil when used in location context (2015)

52 points by wolfskaempf 3y ago

Asraelite 3y ago
> 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?
- pianohacker 3y ago
  This entire article feels like blaming users for being confused by a confusing configuration language with unclear feedback.
  - gnulinux 3y ago
    This is a lot of software nowadays. Design something extremely confusing, write complicated docs, users scratch their heads hold it the wrong way, things blow up, blame the user for not understanding your mental model. When I write software, the mantra I have is that if a user is capable of going to a bad state using the interface I expose, it's a bug on my end. It doesn't change anything whether it's a silly mistake, gross misunderstanding of the API, literal illiteracy, confusion induced by alcohol poisoning... If a user uses your interface and encounters an issue, it's on you to prevent it and tell the user "doing X is not supported, don't do it" instead of either (1) segfaulting or (2) accepting it, leading to subtle bugs.
- klauserc 3y ago
  Yeah, that caught my attention as well. How is SIGSEGV ever _not_ a bug? 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.
- Thaxll 3y ago
  That's what you get when using an http server written in C. Don't get me wrong, Nginx is great, but configuration error should not end up in segfault.
  - stephenr 3y ago
    I don't recall Apache ever segfaulting on me due to config error, and what's more it has an <If> construct that both works as expected and is well documented.
    - btilly 3y ago
      I do. Worse yet. I recall Apache segfaulting inconsistently on different machines. Very specifically segfaulting inside of MY modperl code in a way that logically should have been impossible, but ONLY in production. And not, say, in staging where I could have debugged it. I forget what the configuration error was. (This happened in 2009.) But I very painfully remember it taking over a month before anyone tracked it down. And when I tracked it down, it was because I was reading documentation for some other reason. I noticed the configuration mentioning that segfaults were possible if you did something, so I looked, and we did. I was...not exactly happy.
      - winternewt 3y ago
        I think what they mean is really the developers considering a segfault as the intended result of bad user input.
        btilly 3y ago
        Which "they"? C definitely considers a segfault as the intended result of bad user input. Perl actually has the dump function to create a segfault. Lots of configurations for lots of things have, "This gives you speed+flexibility but is unsafe." In all of these cases, the intended result of bad user input is a segfault. It just comes with the territory. For example nginx allows third party modules to be loaded. There is no way to avoid the fact that some third party modules will dump core. Should nginx therefore stop allowing third party modules? How is that fundamentally different?
justin_oaks 3y ago
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-configuration-inheritance-model/ https://blog.martinfjordvald.com/understanding-the-nginx-con...
- ris 3y ago
  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 3y ago
    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.
asimops 3y ago
Use this static analyzer to check for such mistakes: https://github.com/yandex/gixy https://github.com/yandex/gixy
yencabulator 3y ago
This is architectural shittiness on the level of PHP... it scares me that some very large sites operate on software that'll happily not do what was configured (without signaling errors) or downright corrupt memory on simple user errors. Lots of sites use NGINX as their "first line of defense".
otikik 3y ago
I think title is not confirming to the guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
- forbiddenlake 3y ago
  I'm confused, it[0] is the original title (in the green box at the top). [0] "If is Evil when used in location context"
  - misnome 3y ago
    Perhaps they meant the ellipsis... Which I assume was stripped automatically by the HN title formatter?
  - wetpaws 3y ago
    [dead]
- 0xffff2 3y ago
  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.
  - refulgentis 3y ago
    [flagged]
    - refulgentis 3y ago
      [flagged]
    - pvg 3y ago
      Just flag the bad articles - it works a lot better than meta comments about articles/voting which end up not doing much. Small tutorial bits with clickbait-ish titles are eminently flaggable.

52 points by wolfskaempf 3y ago

> 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?

pianohacker 3y ago
This entire article feels like blaming users for being confused by a confusing configuration language with unclear feedback.
- gnulinux 3y ago
  This is a lot of software nowadays. Design something extremely confusing, write complicated docs, users scratch their heads hold it the wrong way, things blow up, blame the user for not understanding your mental model. When I write software, the mantra I have is that if a user is capable of going to a bad state using the interface I expose, it's a bug on my end. It doesn't change anything whether it's a silly mistake, gross misunderstanding of the API, literal illiteracy, confusion induced by alcohol poisoning... If a user uses your interface and encounters an issue, it's on you to prevent it and tell the user "doing X is not supported, don't do it" instead of either (1) segfaulting or (2) accepting it, leading to subtle bugs.
klauserc 3y ago
Yeah, that caught my attention as well. How is SIGSEGV ever _not_ a bug? 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.
Thaxll 3y ago
That's what you get when using an http server written in C. Don't get me wrong, Nginx is great, but configuration error should not end up in segfault.
- stephenr 3y ago
  I don't recall Apache ever segfaulting on me due to config error, and what's more it has an <If> construct that both works as expected and is well documented.
  - btilly 3y ago
    I do. Worse yet. I recall Apache segfaulting inconsistently on different machines. Very specifically segfaulting inside of MY modperl code in a way that logically should have been impossible, but ONLY in production. And not, say, in staging where I could have debugged it. I forget what the configuration error was. (This happened in 2009.) But I very painfully remember it taking over a month before anyone tracked it down. And when I tracked it down, it was because I was reading documentation for some other reason. I noticed the configuration mentioning that segfaults were possible if you did something, so I looked, and we did. I was...not exactly happy.
    - winternewt 3y ago
      I think what they mean is really the developers considering a segfault as the intended result of bad user input.
      - btilly 3y ago
        Which "they"? C definitely considers a segfault as the intended result of bad user input. Perl actually has the dump function to create a segfault. Lots of configurations for lots of things have, "This gives you speed+flexibility but is unsafe." In all of these cases, the intended result of bad user input is a segfault. It just comes with the territory. For example nginx allows third party modules to be loaded. There is no way to avoid the fact that some third party modules will dump core. Should nginx therefore stop allowing third party modules? How is that fundamentally different?

justin_oaks 3y ago

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-configuration-inheritance-model/ https://blog.martinfjordvald.com/understanding-the-nginx-con...

ris 3y ago
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 3y ago
  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.

asimops 3y ago

Use this static analyzer to check for such mistakes: https://github.com/yandex/gixy https://github.com/yandex/gixy

yencabulator 3y ago

This is architectural shittiness on the level of PHP... it scares me that some very large sites operate on software that'll happily not do what was configured (without signaling errors) or downright corrupt memory on simple user errors. Lots of sites use NGINX as their "first line of defense".

otikik 3y ago

I think title is not confirming to the guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

forbiddenlake 3y ago
I'm confused, it[0] is the original title (in the green box at the top). [0] "If is Evil when used in location context"
- misnome 3y ago
  Perhaps they meant the ellipsis... Which I assume was stripped automatically by the HN title formatter?
- wetpaws 3y ago
  [dead]
0xffff2 3y ago
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.
- refulgentis 3y ago
  [flagged]
  - refulgentis 3y ago
    [flagged]
  - pvg 3y ago
    Just flag the bad articles - it works a lot better than meta comments about articles/voting which end up not doing much. Small tutorial bits with clickbait-ish titles are eminently flaggable.