[HN Gopher] If is Evil when used in location context (2015)
___________________________________________________________________
If is Evil when used in location context (2015)
Author : wolfskaempf
Score : 44 points
Date : 2023-08-23 13:44 UTC (9 hours ago)
(HTM) web link (www.nginx.com)
(TXT) w3m dump (www.nginx.com)
| asimops wrote:
| Use this static analyzer to check for such mistakes:
| https://github.com/yandex/gixy
| otikik wrote:
| I think title is not confirming to the guidelines.
|
| https://news.ycombinator.com/newsguidelines.html
|
| > Otherwise please use the original title, unless it is
| misleading or linkbait; don't editorialize.
| forbiddenlake wrote:
| 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 wrote:
| Perhaps they meant the ellipsis... Which I assume was
| stripped automatically by the HN title formatter?
| wetpaws wrote:
| [dead]
| 0xffff2 wrote:
| 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.
| wiredfool wrote:
| I see "if is evil if used in a location context" (sorry, iOS,
| can't copy).
|
| Coupled with the nginx.com domain, I know exactly what the
| page is and why it's linked here.
| mrguyorama wrote:
| > (sorry, iOS, can't copy)
|
| What, are you a time traveler from 2009? Since when does
| iOS not allow you to copy text on a webpage?
| wiredfool wrote:
| When you're trying to select and copy the link text from
| a link.
| refulgentis wrote:
| [flagged]
| pvg wrote:
| 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.
| refulgentis wrote:
| [flagged]
| [deleted]
| [deleted]
| justin_oaks wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Asraelite wrote:
| > 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 wrote:
| This entire article feels like blaming users for being confused
| by a confusing configuration language with unclear feedback.
| gnulinux wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ashleyn wrote:
| I may be one of the biggest Rust evangelicals, but C isn't an
| excuse for a design that considers segfaulting expected
| behaviour on invalid user input. That points more to a lack
| of validation where needed, nothing that C makes impossible
| or even hard to do.
| stephenr wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-23 23:01 UTC)