I still remember pronouncing it as nging-eks, not engine-eks.
Do svidaniya, Igor, and thank you for Nginx
321–330 of 366 posts
Re: Do svidaniya, Igor, and thank you for Nginx
#322Earlier quoted context omitted.
I mean there was lighttpd before nginx and they have/had pretty similar structures, weights, etc. I feel like I knew at one point why it got so thoroughly supplanted by nginx but I don't remember now why that happened.
From my limited experience, lighttpd has non-stellar documentation and the community (including devs) is kinda rude. nginx has better documentation and a much more welcoming support community. At least for the tasks I use it for (proxying a bunch of random services on a home server), the syntax is a lot easier than lighttpd and it's easier to bring in goodies as modules that would require recompilation on the lighttp…
Not sure which year (decade? :P) you're talking about but in the beginning (before 2010, maybe 2007-08?) Jan was still kinda involved in the German PHP scene and I can't imagine that to be true, I only remember good interactions and we were one of the heaviest users of lighttpd back then. But the docs were never that great, and it seemed to be a one man show, later with a very small team, that's when I think it stalled and only picked up pace years later.
But there indeed came a time (maybe 2010ish?) where nginx took the lead with gread strides and most people (even the die-hard fans) mostly moved to nginx, that's about when it was clear that it would probably win and stay for the forseeable future. Back in those circles at least (see some other comments for the PHP FPM story) Apache was only kept for setups with lots of different other dependencies, like mod_svn or webdav, if you "only" needed a webserver to front PHP it was nginx.
I also remember many people holding out on adopting Apache 2.2 for a looong time.
Re: Do svidaniya, Igor, and thank you for Nginx
#323Earlier quoted context omitted.
By the mid 2010s it had definitely proved its mettle. Arguing that it wouldn't have provided enough benefit to justify the switch is different than saying it was unproven by that point.
No, switching creates risks. Risk of configuration errors leading to downtimes or vulnerabilities, risk of unexpected delays in deployment, risk of running into bugs that the users are unaware of. Many software projects fail by facing delays due to excessive complexity and tech churn. Moving carefully helps.
> No, switching creates risks.
Absolutely - but again, that's apparently not why NGINX was dismissed as an option.
Re: Do svidaniya, Igor, and thank you for Nginx
#324Earlier quoted context omitted.
Granted I've done exactly this before, but why put Nginx in front of Apache? In my experience it added headaches without any real benefit. (Unless you don't mean Apache webserver but rather some other Apache product)
Nginx manages a ton of connections better and can serve static files very fast. It can then multiplex the dynamic requests into fewer connections to Apache. If you mean why not only use nginx, I would guess that's easier than changing your legacy systems to use nginx (e.g. if you have a ton of htaccess files). It's also possible you got better performance with mod_php although most people seem to claim that php-fpm w…
> If you mean why not only use nginx
Yes, this is what I meant. I originally wrote a SaaS app that was hosted through Apache and ended up putting NGINX on top of it for the aforementioned reasons. But eventually testing showed that removing Apache just made the whole thing a whole lot more manageable. I have friends with similar anecdotes. Just putting NGINX in front from the get-go would have saved a lot of tech debt.
Re: Do svidaniya, Igor, and thank you for Nginx
#325Earlier quoted context omitted.
> On the other hand, the unreadable weird-ass pseudo-XML configuration files If I have one gripe about NGINX it's that its configuration is a still-half-baked DSL that has quirks you wouldn't expect and when they error you don't get great feedback. Examples: You can have an if clause, but no else attached. You can't have an if clause with multiple conditions. Finally, "if [might be] evil." 1 You end up writing a bunc…
With the rewrite and map blocks it is maybe a little easier for you to write fewer if statements…. https://stackoverflow.com/questions/47724946/nginx-rewrite-b...
Oh I've used these plenty but there are still conditionals which sometimes require or are most clearly defined with if statements, particularly complex redirects that rely on a number of individual conditions to be met.
I've seen these manifest in the wild as stuff like:
if ($thing ~* (match)) { $setWeirdVar = "Y"; } if ($otherThing = "value") { set $setValue "${setWeirdVar}E"; } if ($thirdCondition ~ (another|match)) { set $setValue "${setWeirdVar}S"; } if ($setValue = YES) { # do a thing here }
As clunky as that is, I've found it recommended in SO threads.
Re: Do svidaniya, Igor, and thank you for Nginx
#326Earlier quoted context omitted.
I mean there was lighttpd before nginx and they have/had pretty similar structures, weights, etc. I feel like I knew at one point why it got so thoroughly supplanted by nginx but I don't remember now why that happened.
The difference is that nginx really works. I had Panoramio, a photo website featured in Google Earth / Maps, using Apache. It started to fail down under load, and I quickly switched to lighttpd. It was faster but crashing, getting OOM, etc. I fixed a memory leak and a few more bugs, but it still crashed every now and then and I looked for alternatives. This was 2006 and nginx was the only realistic alternative on the…
Panoramio was so good. I had photos there. People wrote me comments. Then Google just killed it. Fuck them.
Re: Do svidaniya, Igor, and thank you for Nginx
#327Earlier quoted context omitted.
Cloudflare uses a heuristic trust model where it pulls multiple trust signals from the client. It can use several things (including stable IP address, cookies, and I think even a bit of JavaScript grabbing a nonce from local storage). If you run with a lot of "identity fuzzers" (browsing through Tor, JavaScript off, cookies banned), Cloudflare can't build its trust heuristics and needs to challenge-response more ofte…
Just plain Chrome Mobile, nothing else, no VPN.
Interesting. The only other thing that immediately comes to mind is that the web site owner may have blocked the entire country (https://support.cloudflare.com/hc/en-us/articles/200170136-U...). This would be easiest to verify by seeing if other people with similar phone configuration standing next to you get the same experience.
Re: Do svidaniya, Igor, and thank you for Nginx
#328Earlier quoted context omitted.
What's the alternative? Abusive traffic is the norm rather then an exception. This gets into the same argument when people say they don't need a CDN; it's a relic from when bad actors were rare.
If all I'm doing is requesting an HTML page, why do they have to send me a CAPTCHA? I understand that my request is coming from an IP belonging to a VPN and maybe someone used the same IP nefariously, but I doubt they requested the same page I have.
You can knock over a server with malicious requests of static content. In fact, what you are describing (requesting different pages) is the first step to trying to defeat a firewall rule that would protect against that attack.
This is the era after the invention of Low Orbit Ion Cannon. Attacks that would previously have been technically sophisticated can now be done with a few GitHub downloads and either many volunteers or many compromised machines.
Re: Do svidaniya, Igor, and thank you for Nginx
#329Earlier quoted context omitted.
Wordpress had some say in this i think.
Definitely. I've founded and grew several webhosters, one specialised in WordPress. Our HTTP stack was varnish->nginx(loadbalancer)->nginx->phpfpm. It was pain. Not even WordPress core could (can?) run all its features; e.g. the SEO-friendly-URL thing relied (relies?) heavily on - I kid you not - rewriting the .htaccess file from the CMS: really: the CMS rewriting webserver configuration files from the web. Let alone…
I don't recognize anything about the WP Apache marriage.
Re: Do svidaniya, Igor, and thank you for Nginx
#330Earlier quoted context omitted.
On the other hand, the unreadable weird-ass pseudo-XML configuration files of Apache made anyone touching them wish for something better. I also expect ngx_lua did a lot for adoption, the fact that you could always "shell out" to lua if you needed was a huge boon even just for peace of mind.
> On the other hand, the unreadable weird-ass pseudo-XML configuration files If I have one gripe about NGINX it's that its configuration is a still-half-baked DSL that has quirks you wouldn't expect and when they error you don't get great feedback. Examples: You can have an if clause, but no else attached. You can't have an if clause with multiple conditions. Finally, "if [might be] evil." 1 You end up writing a bunc…
I agree with you completely. Nginx's config syntax is better than Apache's but it still feels like mystery meat. Can you use this directive or option within this block? Maybe, maybe not. If not, why? Who knows. It's just not allowed to use map within a location block and that's just how it is, okay?
My dream web server has Nginx's capabilities and Lighttpd's Lua configuration files/scripts. Is that what ngx_lua does? I've heard of it before but never really gave it a look.