Live data from Hacker News

If is Evil when used in location context (2015)

nginx.com

21–30 of 31 posts

Re: If is Evil when used in location context (2015)

#21
post #17

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

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.

I don't recall Apache ever segfaulting on me due to config error, and what's more it has an construct that both works as expected and is well documented.

Re: If is Evil when used in location context (2015)

#22
post #4

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.

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.

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

Re: If is Evil when used in location context (2015)

#23

Earlier quoted context omitted.

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.

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

When you’re trying to select and copy the link text from a link.

Re: If is Evil when used in location context (2015)

#24
post #17

Earlier quoted context omitted.

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.

I don't recall Apache ever segfaulting on me due to config error, and what's more it has an construct that both works as expected and is well documented.

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.

Re: If is Evil when used in location context (2015)

#26
post #17

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

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.

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.

Re: If is Evil when used in location context (2015)

#27
post #26
post #17

Earlier quoted context omitted.

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.

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.

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.

Re: If is Evil when used in location context (2015)

#28
post #24

Earlier quoted context omitted.

I don't recall Apache ever segfaulting on me due to config error, and what's more it has an construct that both works as expected and is well documented.

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 d…

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

Re: If is Evil when used in location context (2015)

#29
post #24

Earlier quoted context omitted.

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 d…

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

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?

Re: If is Evil when used in location context (2015)

#30
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".
Post reply on HN