Live data from Hacker News

Nginx 1.6.0 stable released

nginx.org

111–114 of 114 posts

Re: Nginx 1.6.0 stable released

#111

Earlier quoted context omitted.

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.

oh right, that makes more sense.

Re: Nginx 1.6.0 stable released

#112
post #69
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…

Thanks, I will try this, it looks like it will work.

It does work, thanks!

Re: Nginx 1.6.0 stable released

#113

Earlier quoted context omitted.

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

No, I was thinking about the original auth_request. For cookies based authentication you need to turn off authorization for login pages (because every visitor should be allowed to access login pages) and pass login requests directly to your auth backend. The auth backend can then verify password, set cookies etc. auth_request failures 401, 403 can also be configured to show login page to the user.

Here is a config that does something like this: https://github.com/wrr/wwwhisper/blob/master/nginx/wwwhisper... (deployed here: https://io-mixedbit.rhcloud.com)

(Sorry for the late reply)

Re: Nginx 1.6.0 stable released

#114
post #100

Earlier quoted context omitted.

Unless you want to use Nginx as an SSL-offloading proxy for a bunch of internal apps that you want to protect from the public but your apps themselves don't use the session in any way? Yes, we can use Lua and effectively write our own, but one of the reasons I've considered Apache again is that there's now a plugin for OAuth 2 + OpenID Connect ;-) https://github.com/pingidentity/mod_auth_openidc That said, even befor…

Put Nginx in front of Apache then? Or set up an authentication service and use it from your internal apps?

You'll lose some of the benefits of Nginx at that point, since part of why people like Nginx is how it handles connections, proxying and caching. And the internal apps aren't always mine to maintain, e.g. Apple's Xcode server.

But yeah, there are options in Apache-land, my post was more that nginx could eventually gain those options too :)

Post reply on HN