Changes with nginx 0.7.42 16 Mar 2009 *) Change: now the "Invalid argument" error returned by setsockopt(TCP_NODELAY) on Solaris, is ignored. *) Change: now if a file specified in a "auth_basic_user_file" directive is absent, then the 405 error is returned instead of the 500 one. *) Feature: the "auth_basic_user_file" directive supports variables. Thanks to Kirill A. Korinskiy. *) Feature: the "listen" directive supports the "ipv6only" parameter. Thanks to Zhang Hua. *) Bugfix: in an "alias" directive with references to captures of regular expressions; the bug had appeared in 0.7.40. *) Bugfix: compatibility with Tru64 UNIX. Thanks to Dustin Marquess. *) Bugfix: nginx could not be built without PCRE library; the bug had appeared in 0.7.41.
on 2009-03-16 08:42
on 2009-03-16 08:53
2009/3/16 Igor Sysoev <firstname.lastname@example.org>: > Â Â *) Change: now if a file specified in a "auth_basic_user_file" > Â Â Â directive is absent, then the 405 error is returned instead of the > Â Â Â 500 one. Shouldn't it be a 403? 405 doesnt' seem right there.
on 2009-03-16 08:56
On Mon, Mar 16, 2009 at 12:45:37AM -0700, mike wrote: > 2009/3/16 Igor Sysoev <email@example.com>: > > > š š*) Change: now if a file specified in a "auth_basic_user_file" > > š š š directive is absent, then the 405 error is returned instead of the > > š š š 500 one. > > Shouldn't it be a 403? 405 doesnt' seem right there. Yes, this is typo.
on 2009-03-16 09:44
Excellent. Thanks for the quick release! This is going on production right now :) For the future it might be cool to also allow for "auth_basic" to also accept the variable too (for customized realm names) 2009/3/16 Igor Sysoev <firstname.lastname@example.org>:
on 2009-03-16 15:26
Nginx 0.7.42 for Windows is now available: http://cli.gs/742 -- Kevin Worthington
on 2009-03-17 18:10
Any idea when 0.7xx new features will be backported to stable tree (0.6)? Thanks.
on 2009-03-17 18:24
How about when it will be deemed stable (been running it fine ever since I decided to use nginx ...) and consider 0.6.x legacy instead? :) 2009/3/17 Athan Dimoy <email@example.com>:
on 2009-03-17 18:56
good catch. Why 0.7 is not considered stable?
on 2009-03-17 19:48
I would guess that it will be stable when Igor releases 0.8.x. However, did PHP fastcgi recently break? I am referring to the incorrect server name as 0.0.0.0 - maybe it isn't broken, just saying, perhaps possible issues like this is why. Also, more importantly, new features have been introduced that are still going through iterations (the try_files directive, specifically). Generally, this is what staves off "stable-ness". This is why debian packages are so old in the stable branch, btw - they do not update package versions or add new packages except for security concerns - this is what makes it stable (rarely changing), as opposed to volatile (often changing) system. That said, many of us use the development branch in production, as really a recompile of the binary is no problem when you can switch the processes with zero downtime :). NginX is one of the better programs out there to have on the cutting edge; Igore is from what I've seen very careful in what he adds or changes and it always seems to be improving, with fewer bugs being introduced than fixed (which is awesome!). - Merlin
on 2009-03-17 20:35
i would think it's nginx's fastcgi, not php's fastcgi. nginx's told to fastcgi_param SERVER_ADDR the same, and the version of nginx changed, nothing else - PHP didn't, etc. so the problem from that angle is localized to something on the nginx side.
on 2009-03-17 20:59
It should be easy to test. Define fastcgi_param SERVER_ADDR as a constant (say your real IP) in your fastcgi_params file and see what's passed in phpinfo. BTW, a similar bug appeared before and I pulled my hair out over it. Igor did subsequently fix it in 0.7.20. It's in the changelog. Sent from my Verizon Wireless BlackBerry
on 2009-03-18 15:41
+1 for 0.7.* to be stable