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.
2009/3/16 Igor S. [email protected]:
  *) 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 Mon, Mar 16, 2009 at 12:45:37AM -0700, mike wrote:
2009/3/16 Igor S. [email protected]:
š š*) 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.
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 S. [email protected]:
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 D. [email protected]:
good catch.
Why 0.7 is not considered stable?
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!).
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.
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
Any idea when 0.7xx new features will be backported to stable tree
(0.6)?
Thanks.
+1 for 0.7.* to be stable