[Asraelite]

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

This entire article feels like blaming users for being confused by a confusing configuration language with unclear feedback.

[gnulinux]

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]

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]

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]

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.

[carlmr]

It isn't an excuse, but having worked with C and Rust programmers, C programmers IME tend to have attitudes blaming users for not RTFM and Rust programmers (again IME, not generalizing) have more of the opinion that illegal states should not be reachable through public API, i.e. blame the designer, not the user.

I think it's reflective of Rust vs C design philosophy.

[stephenr]

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]

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]

I think what they mean is really the developers considering a segfault as the intended result of bad user input.

[btilly]

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?

[winternewt]

"They" as in the software developers. I disagree that C as a language has any opinion on whether segfault (or undefined behavior) is an acceptable outcome for user input. That depends on the use case.

Plugins are software, and all software can crash because validation is not just practically but even theoretically impossible for a Turing-complete language. But the fundamental difference is not in whether a crash can occur or not, but in your attitude to the crash: is it a software bug and hence should be fixed, or is it expected behavior and left as is? IMO the former attitude is almost always the correct one if the end user is anybody other than yourself.

There may be performance concerns that make it worthwhile to accept a crash (and that's the reason we run plugins as in-process native code instead of in a separate process or VM) but in the case of nginx I strongly doubt performance would be affected noticeably by validation of config files.