Nginx 1.6.0 stable released • Hacker News Board

Re: Nginx 1.6.0 stable released

#101

Post by pas » Fri, Apr 25, 2014, 1:38 AM UTC

bithive123 wrote: post #72

feld wrote: post #68

Earlier quoted context omitted.

this reminds me of a government agency that permits access by IP addresses whitelisted in IIS. Can't put fancy caching or load balancing in front because it can't understand X-Forwarded-For, etc. tl;dr build your authentication into your app, not the web server layer.

There are plenty of upsides to decoupling authentication from your app codebases. For instance, in an enterprise where you have a single sign-on solution implemented as a web server module and a mix of third party and bespoke web apps.

I think no one argues that decoupling isn't the way, in fact that's exactly what others are saying too, but in the proper way. Make an authentication (micro)service and call it from your webapp. Proxy should proxy, auth service should manage (and cache, keep up to date) credentials, role associations and group memberships, web app should serve web pages (based on the business logic coded into it).

Re: Nginx 1.6.0 stable released

#102

Post by pas » Fri, Apr 25, 2014, 1:41 AM UTC

leccine wrote: post #20

Most of the best features are in the paid version. I am leaning towards replacing Nginx with Haproxy for the reverse proxying part, unless they move at least the advanced load-balancing features to the free version.

Have you considered Hipache? ( https://github.com/dotcloud/hipache )

Re: Nginx 1.6.0 stable released

#103

Post by sondr3 » Fri, Apr 25, 2014, 2:35 AM UTC

marshallford wrote: post #61

Spittie wrote: post #59

Earlier quoted context omitted.

By the way, the nginx wiki says that you should avoid ifs when possible: http://wiki.nginx.org/IfIsEvil Wouldn't something like this accomplish the same thing? (Sorry if I'm totally wrong, I'm not really good) location /google/ { } location /y_key_/ { } location ~ \.html$ { return 404; } location = /index { return 404; } location / { try_files $uri @rewrite } location @rewrite { rewrite ^/$ /index.html break; rewrite…

This is yet another concern of mine. Most of my solutions involve at least 3 if statements. But I need them in order to check if a requested url is a directory or a file and such.

What kind of app are you running that requires you to do something like this for clean URLs?

Re: Nginx 1.6.0 stable released

#104

Post by w-ll » Fri, Apr 25, 2014, 3:55 AM UTC

marshallford wrote: post #26

ShaneOG wrote: post #22

Earlier quoted context omitted.

Have you checked out https://github.com/h5bp/server-configs-nginx ?

Yes I have, however I always find it very challenging to modify it to support clean urls and PHP-FPM in an OCD fashion.

Have you tried handling your urls in php? Most apps/frameworks I've worked on in the past few years all do better url mgmt then you are probably going to get with just nginx configs.

Re: Nginx 1.6.0 stable released

#105

Post by kolev » Fri, Apr 25, 2014, 5:48 AM UTC

All good, but Nginx is really playing a nasty game now. Basic features such as proxy_cache_purge are available in the commercial version only.

Re: Nginx 1.6.0 stable released

#106

Post by porker » Fri, Apr 25, 2014, 7:48 AM UTC

e12e wrote: post #79

porker wrote: post #44

Earlier quoted context omitted.

> I would normally advice an architecture where you have a reverse proxy in front of application servers My understanding too is that as we containerize more applications (whether this be Jails, Zones or Docker) then for shared-IP addresses (e.g. VirtualHosts) we need a reverse proxy to do the mapping to the correct container. Do you know anything about this, as my research hasn't found anything?

Well, if you're not using ipv6 it can be a bit tricky to map a (public) ip to each application server/container/whatnot. For web services you need a front-end router/proxy that understands http host headers and/or SNI (for ssl). If you have that, you can map stuff in DNS, and still use just port 80/443 on the "user facing" side: client sends "host: some.service.example.com" -> proxy (alias for some.service.example.co…

Thanks, it's interesting to hear about the different options. I've not even thought about IPv6 yet and the options I'd have using that internally. I'm never going to have enough public IPv4 addresses for the number of containers so something has to happen.

Re: Nginx 1.6.0 stable released

#107

Post by odonnellryan » Fri, Apr 25, 2014, 11:46 AM UTC

marshallford wrote: post #55

saurik wrote: post #49

Earlier quoted context omitted.

foo.com/* -> www.foo.com/* seems "cleaner" to me than your opposite, due to the issues with cookie leaking, CDN hosting, "normal user" expectations, etc. Like, please appreciate that your usage of "cleaner" is at best subjective ;P. (And I don't quite understand how you are intending to do "foo.com/ -> foo.com"... all URLs must have a path: you can't just GET, you have to GET /.)

I understand the redirecting to non-www is subjective, however I find less characters in the URL is cleaner. Also for a majority of my projects cookies are not used, so it is not a big deal to use a non-www base url.(Static blogs and simple vanilla sites for various school projects, etc). Also as far as foo.com/ -> foo.com, I was referring to the URL, not the acutal path. example: https://www.google.com/ redirects to…

I think that's just your browser removing the trailing slash.

Re: Nginx 1.6.0 stable released

#108

Post by clarkevans » Fri, Apr 25, 2014, 12:38 PM UTC

mixedbit wrote: post #74

clarkevans wrote: post #45

I wish there were better authentication options with Nginx. The ngx_http_auth_request_module is limited: First, it assumes that the authentication agent doesn't need to talk to the user. Second, it doesn't cache the authentication. Perhaps nginx might instead check all requests for a particular signed cookie, verify the signature, if the signature matches, verify that the cookie isn't too old, and then unpack variabl…

This isn't correct, you can use auth_request when authentication agent needs to talk to the user. I can't even see how it could be used without such communication.

Are you referring to a modified version of ngx_http_auth_request by davidjb that permits 3xx responses, including cookie headers?

http://davidjb.com/blog/2013/04/integrating-nginx-and-a-shib...

For some reason, I thought this behaviour made it to the upstream, till I re-read the official ngx_http_auth_request documentation and realized it doesn't pass through 3xx or headers other than WWW-Authenticate:

  The ngx_http_auth_request_module module (1.5.4+) implements 
  client authorization based on the result of a subrequest. 
  If the subrequest returns a 2xx response code, the access
  is allowed. If it returns 401 or 403, the access is
  denied with the corresponding error code. Any other 
  response code returned by the subrequest is considered 
  an error.  For the 401 error, the client also receives
  the “WWW-Authenticate” header from the subrequest response.

Re: Nginx 1.6.0 stable released

#109

Post by neckro23 » Fri, Apr 25, 2014, 2:01 PM UTC

marshallford wrote: post #55

saurik wrote: post #49

Earlier quoted context omitted.

foo.com/* -> www.foo.com/* seems "cleaner" to me than your opposite, due to the issues with cookie leaking, CDN hosting, "normal user" expectations, etc. Like, please appreciate that your usage of "cleaner" is at best subjective ;P. (And I don't quite understand how you are intending to do "foo.com/ -> foo.com"... all URLs must have a path: you can't just GET, you have to GET /.)

I understand the redirecting to non-www is subjective, however I find less characters in the URL is cleaner. Also for a majority of my projects cookies are not used, so it is not a big deal to use a non-www base url.(Static blogs and simple vanilla sites for various school projects, etc). Also as far as foo.com/ -> foo.com, I was referring to the URL, not the acutal path. example: https://www.google.com/ redirects to…

No, that's just your browser (annoyingly) removing the trailing slash from URL shown in the address bar.

http://www.foo.com/ is the "correct" URL. Remember how HTTP works -- you connect to foo.com port 80, then "GET / HTTP/1.1". You can't just omit the "/" and expect it to work.

HTTP clients will just request "/" if no path is specified, so nginx will never even see a request that matches "^foo.com$". You'll cause an infinite redirect loop if you try to force the issue.

Re: Nginx 1.6.0 stable released

#110

Post by makomk » Fri, Apr 25, 2014, 2:42 PM UTC

cheald wrote: post #12

neverminder wrote: post #10

Earlier quoted context omitted.

Nginx is also non-blocking which is the main difference from Apache. I don't agree Nginx is less flexible, from my own experience it's quite the other way around - try configuring Apache as a reverse proxy, you'll see how "flexible" it really is.

By "flexible", I primarily mean Apache's module system vs nginx's "compile all the things" approach. Upgrading a component in nginx means recompiling the whole webserver, whereas Apache modules can be managed separately from the httpd executable. I'm curious about the reverse proxy comment, though; mod_proxy_balancer generally does the job just fine. I do agree that nginx is easier to set up as a reverse proxy, thoug…

Also, mod_perl essentially lets you write your own Apache modules in Perl with access to a large chunk of the Apache API. It's a little old-fashioned now though.