3 ms·

I feel the same way. I'm not a fan of haproxy's configuration system. It's really difficult for me to understand it, whereas I feel I can read most nginx/apac

by bmurphy1976 4y ago

I feel the same way. I'm not a fan of haproxy's configuration system. It's really difficult for me to understand it, whereas I feel I can read most nginx/apache configs and immediately know what is supposed to be happening. I still maintain servers under load in production that use all three to this day and I always go back to nginx because of the configuration alone.

kilburn 4y ago
I can't comment on haproxy because I haven't used it enough, but I think that the "nginx's config is easy to grasp" posture has a bit of Stockholm syndrome in it. - Do you want to add a header in this "location" block? Great, you better remember to re-apply all the security headers you've defined at a higher level (server block for instance) because of course adding a new header will reset those. - Oh, you mixed prefix locations with exact location with regex locations. Great, let's see if you can figure out by which location block will a request end up being processed. The docs "clearly" explain what the priority rules for those are and they're easy to grasp [1]. - I see you used a hostname in a proxy_pass directive (e.g.: http://internal.thing.com http://internal.thing.com). Great, I will resolve it at startup and never check again, because this is the most sensible thing to do of course. - Oh... now you used a variable (e.g.: http://$internal_host http://$internal_host). That fundamentally changes things (how?) so I'll respect the DNS's TTL now. Except you'll have to set up a DNS resolver in my config because I refuse to use the system's normal resolver because reasons. - Here's an `if` directive for the configuration. It sounds extremely useful, doesn't it? Well.. "if is evil" [2] and you should NOT use it. There be dragons, you've been warned. I could go on... but I think I've proved my point already. Note that these are not complaints, it's just me pointing out that nginx's configuration has its _very_ significant warts too. [1] https://nginx.org/en/docs/http/ngx_http_core_module.html#location https://nginx.org/en/docs/http/ngx_http_core_module.html#loc... [2] https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
- hinkley 4y ago
  All that may be true, but for a lot of us old timers we were coming from apache to nginx and apache's configs can eat a bag of dicks. Unfortunately it's likely I worked in the same building as one of the people responsible for either creating or at least maintaining that mess, but I didn't know at the time that he needed an intervention.
- slivanes 4y ago
  Yes, I've experienced most of these with nginx and it can be a minefield. The best experience I've had configuring a webserver was lighttpd.
  - iforgotpassword 4y ago
    Yes, also a lighttpd fan here. It's not as refined a reverse proxy, but for the halfway trivial use case it's doing fine, and as a web server it's light (duh) and fast. Much more readable configuration than nginx or apache.
- bmurphy1976 4y ago
  To be clear I never said it was easy. I have a LOT of issues with Nginx's configuration, I just find it to be significantly less bad than the other options. Other than Caddy, Caddy has been great so far but I have only used it for personal projects.
- TimWolla 4y ago
  Exactly all of this. I've mentioned the first point about add_header redefining instead of appending in a previous HN comment of mine: https://news.ycombinator.com/item?id=27253579 https://news.ycombinator.com/item?id=27253579. As mentioned in that comment, HAProxy's configuration is much more obvious, because it's procedural. You can read it from top to bottom and know what's happening in which order. Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.

kilburn 4y ago

I can't comment on haproxy because I haven't used it enough, but I think that the "nginx's config is easy to grasp" posture has a bit of Stockholm syndrome in it. - Do you want to add a header in this "location" block? Great, you better remember to re-apply all the security headers you've defined at a higher level (server block for instance) because of course adding a new header will reset those. - Oh, you mixed prefix locations with exact location with regex locations. Great, let's see if you can figure out by which location block will a request end up being processed. The docs "clearly" explain what the priority rules for those are and they're easy to grasp [1]. - I see you used a hostname in a proxy_pass directive (e.g.: http://internal.thing.com http://internal.thing.com). Great, I will resolve it at startup and never check again, because this is the most sensible thing to do of course. - Oh... now you used a variable (e.g.: http://$internal_host http://$internal_host). That fundamentally changes things (how?) so I'll respect the DNS's TTL now. Except you'll have to set up a DNS resolver in my config because I refuse to use the system's normal resolver because reasons. - Here's an `if` directive for the configuration. It sounds extremely useful, doesn't it? Well.. "if is evil" [2] and you should NOT use it. There be dragons, you've been warned. I could go on... but I think I've proved my point already. Note that these are not complaints, it's just me pointing out that nginx's configuration has its _very_ significant warts too. [1] https://nginx.org/en/docs/http/ngx_http_core_module.html#location https://nginx.org/en/docs/http/ngx_http_core_module.html#loc... [2] https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ https://www.nginx.com/resources/wiki/start/topics/depth/ifis...

hinkley 4y ago
All that may be true, but for a lot of us old timers we were coming from apache to nginx and apache's configs can eat a bag of dicks. Unfortunately it's likely I worked in the same building as one of the people responsible for either creating or at least maintaining that mess, but I didn't know at the time that he needed an intervention.
slivanes 4y ago
Yes, I've experienced most of these with nginx and it can be a minefield. The best experience I've had configuring a webserver was lighttpd.
- iforgotpassword 4y ago
  Yes, also a lighttpd fan here. It's not as refined a reverse proxy, but for the halfway trivial use case it's doing fine, and as a web server it's light (duh) and fast. Much more readable configuration than nginx or apache.
bmurphy1976 4y ago
To be clear I never said it was easy. I have a LOT of issues with Nginx's configuration, I just find it to be significantly less bad than the other options. Other than Caddy, Caddy has been great so far but I have only used it for personal projects.
TimWolla 4y ago
Exactly all of this. I've mentioned the first point about add_header redefining instead of appending in a previous HN comment of mine: https://news.ycombinator.com/item?id=27253579 https://news.ycombinator.com/item?id=27253579. As mentioned in that comment, HAProxy's configuration is much more obvious, because it's procedural. You can read it from top to bottom and know what's happening in which order. Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.