Forum: NGINX nginx-0.7.42

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Igor S. (Guest)
on 2009-03-16 09:42
(Received via mailing list)
Changes with nginx 0.7.42                                        16 Mar

    *) 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
       500 one.

    *) Feature: the "auth_basic_user_file" directive supports variables.
       Thanks to Kirill A. Korinskiy.

    *) Feature: the "listen" directive supports the "ipv6only"
       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
       appeared in 0.7.41.
mike (Guest)
on 2009-03-16 09:53
(Received via mailing list)
2009/3/16 Igor S. <removed_email_address@domain.invalid>:

>    *) 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.
Igor S. (Guest)
on 2009-03-16 09:56
(Received via mailing list)
On Mon, Mar 16, 2009 at 12:45:37AM -0700, mike wrote:

> 2009/3/16 Igor S. <removed_email_address@domain.invalid>:
> > š š*) 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.
mike (Guest)
on 2009-03-16 10:44
(Received via mailing list)
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. <removed_email_address@domain.invalid>:
Kevin W. (Guest)
on 2009-03-16 16:26
(Received via mailing list)
Nginx 0.7.42 for Windows is now available:
Kevin W.
Athan D. (Guest)
on 2009-03-17 19:10
(Received via mailing list)
Any idea when 0.7xx new features will be backported to stable tree

mike (Guest)
on 2009-03-17 19:24
(Received via mailing list)
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. <removed_email_address@domain.invalid>:
Walter Cruz (Guest)
on 2009-03-17 19:56
(Received via mailing list)
good catch.

Why 0.7 is not considered stable?
Merlin (Guest)
on 2009-03-17 20:48
(Received via mailing list)
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 - maybe it isn't broken, just saying, perhaps
possible issues like this is why.  Also, more importantly, new features
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
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
zero downtime :).  NginX is one of the better programs out there to have
the cutting edge; Igore is from what I've seen very careful in what he
or changes and it always seems to be improving, with fewer bugs being
introduced than fixed (which is awesome!).

- Merlin
mike (Guest)
on 2009-03-17 21:35
(Received via mailing list)
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.
Jim O. (Guest)
on 2009-03-17 21:59
(Received via mailing list)
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
Tomasz P. (Guest)
on 2009-03-18 16:41
(Received via mailing list)
+1 for 0.7.* to be stable
This topic is locked and can not be replied to.