161–170 of 501 posts
Earlier quoted context omitted.
if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!
If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
Earlier quoted context omitted.
HAProxy is an enterprise load balancer that's available through Red Hat or other OSS Vendor. Nginx is just so easy to configure...
HAProxy is a wonderful load balancer that doesn't serve static files thus forcing many of us to learn Nginx to fill the static-file-serving scenarios. Caddy seems like a wonderful alternative that does load balancing and static file serving but has wild config file formats for people coming from Apache/Nginx-land.
This method is also useful for abusive clients that one still wishes to give an error page to. Based on traffic patterns, drop them in a stick table and route those people to your pre-compressed error page in the unique back-end. It keeps them at the edge of the network.
Time for me to slowly start looking for an alternative. There was a time when I wanted to move away from it and was eyeing HAProxy, but the lack of the ability to serve static files didn't convince me. Then there was Traefik, but I never looked too much into it, because Nginx is working just fine for me. My biggest hope was Cloudflare's Rust-based Pingora pre-announcement, which was then never published as Open Sourc…
I mean I’m not sure how it’s good to want to move to a dev who is against CVEs and disclosures…
I could have sworn that I've read about Nginx CVEs in the past.
What a coincidence, some days ago I was reading some HN posts related to lighttpd and I found [1]. The link is dead and it has inappropriate content, so use arhive.org. The author doesn't go too much in detail of why nginx being purchased is a problem, but in how to configure lighttpd. And the first comment predicts the hypothetical case of F5 being problematic. [1] https://news.ycombinator.com/item?id=19413901
I have been using lighttpd which can also host static content and do proxying, on top of those lighttpd supports cgi/fastcgi/etc out of the box as well, and it takes 4MB memory only by default at start, so it works for both low end embedded systems and large servers.
I didn't compile in fastcgi support in to my build, but it can be enabled.
Tangent, but I got curious about contributing so I went to the Freenginx homepage, it looks like this project will be organized over mailing list. I would love if someone would create a product that gives mailing list a tolerable UI.
Tangent, but I got curious about contributing so I went to the Freenginx homepage, it looks like this project will be organized over mailing list. I would love if someone would create a product that gives mailing list a tolerable UI.
https://mail.python.org/archives/list/mailman-users@python.o...
Earlier quoted context omitted.
Yeah, I've been with F5 since 2010 - gotta love those old PortMasters though, Livingston was good times, until Lucent took over. I was there 95-98. I don't know what else there is to say really. The QUIC/HTTP/3 vuln was found in NGINX OSS, which is also the basis for the commercial NGINX+ product. We looked at the issue and decided that, by our disclosure policies, we needed to assign a CVE and make a disclosure. And…
> Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works. Even if third parties can file CVEs, do you think it hits different when the parent organization decides to do so against the developer's wishes? Why do he and F5 view the bugs differently? It sounds like the fork decision was motivated less by the actual CVEs and more about how the decision…
Based on my observation of various NGINX forums and mailing lists, the HTTP/3 feature, while experimental, is seeing adoption by the leading edge of web applications, so I don't think it could be argued that its not being slowly rolled into production in places.