Nginx-1.1.12

luislavena · December 26, 2011, 4:49pm

Changes with nginx 1.1.12 26 Dec
2011

*) Change: a "proxy_pass" directive without URI part now uses

changed
URI after redirection with the “error_page” directive.
Thanks to Lanshun Zhou.

*) Feature: the "proxy/fastcgi/scgi/uwsgi_cache_lock",
   "proxy/fastcgi/scgi/uwsgi_cache_lock_timeout" directives.

*) Feature: the "pcre_jit" directive.

*) Feature: the "if" SSI command supports captures in regular
   expressions.

*) Bugfix: the "if" SSI command did not work inside the "block"

command.

*) Bugfix: the "limit_conn_log_level" and "limit_req_log_level"
   directives might not work.

*) Bugfix: the "limit_rate" directive did not allow to use full
   throughput, even if limit value was very high.

*) Bugfix: the "sendfile_max_chunk" directive did not work, if the
   "limit_rate" directive was used.

*) Bugfix: a "proxy_pass" directive without URI part always used
   original request URI if variables were used.

*) Bugfix: a "proxy_pass" directive without URI part might use

original
request after redirection with the “try_files” directive.
Thanks to Lanshun Zhou.

*) Bugfix: in the ngx_http_scgi_module.

*) Bugfix: in the ngx_http_mp4_module.

*) Bugfix: nginx could not be built on Solaris; the bug had appeared

in
1.1.9.

Maxim D.

Maxim_D · December 26, 2011, 7:43pm

Hello Nginx U.s,

Just released: Nginx 1.1.12 For Windows Nginx 1.1.12 for Windows – Kevin Worthington (32-bit
and 64-bit versions)

These versions are to support legacy users who are already using
Cygwin based builds of Nginx. Official Windows binaries are at
nginx.org

Thank you,
Kevin

Kevin W.
kworthington *@~ #gmail} [dot) {com]

Maxim_D · December 27, 2011, 12:37am

How to use pcre_jit?

Maxim_D · December 27, 2011, 10:32am

Hi,

Not sure which bugfix did this, but nginx 1.1.12 causes redirect loop on
one of my vhosts, which is a wordpress blog. Config below. nginx 1.1.11
works fine for this vhost.

server {

listen 192.168.2.5:80 default;

    location / {

        location ~ /\.ht {
            deny  all;
        }

        proxy_redirect off;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For

$proxy_add_x_forwarded_for;

        client_max_body_size       25m;
        client_body_buffer_size    128k;

        proxy_connect_timeout      300;
        proxy_send_timeout         300;
        proxy_read_timeout         300;

        proxy_buffering on;
        proxy_buffer_size          32k;
        proxy_buffers              32 4k;
        proxy_busy_buffers_size    64k;
        proxy_max_temp_file_size 0;

        access_log off;
        proxy_pass   http://192.168.2.5:8080;

    }

Maxim_D · December 27, 2011, 12:20pm

Hello!

On Tue, Dec 27, 2011 at 11:31:28AM +0200, Boyko Y. wrote:

        client_body_buffer_size    128k;

        access_log off;
        proxy_pass   http://192.168.2.5:8080;

    }

Could you please show debug log? See
Debugging | NGINX for details.

Maxim D.

Maxim_D · December 27, 2011, 10:46am

On Tuesday 27 December 2011 03:37:15 lhmwzy wrote:

How to use pcre_jit?

pcre_jit on; - in the main context (root level of your nginx.conf).

It enables PCRE Jist-in-Time compilation on nginx configuration phase.
This
can speed up matching for all regular expressions in your config up to
10 times.
More info: Redirect to GitHub

The directive only works for nginx compiled with PCRE library 8.20 or
above.
Also, PCRE must be configured with --enable-jit flag.

If you compile PCRE with nginx (the “–with-pcre=path/to/sources” flag),
you can
also set the “–with-pcre-jit” flag to enable JIT support (PCRE >=
8.20).

wbr, Valentin V. Bartenev

Maxim_D · December 28, 2011, 1:32pm

Hi,

The quick fix did the trick.

Maybe best if changelog entries contain info whether new
features/bugfixes require updating current nginx configuration to
preserve nginx behavior with newer version or similar?

Having in mind I’m using relatively common nginx configuration/apache
backend, once these changes are applied to the stable release they will
probably affect many others?

Many thanks!

Boyko

Maxim_D · December 28, 2011, 6:20pm

Hello!

On Tue, Dec 27, 2011 at 09:29:38PM +0200, Boyko Y. wrote:

The quick fix did the trick.

Maybe best if changelog entries contain info whether new
features/bugfixes require updating current nginx configuration
to preserve nginx behavior with newer version or similar?

Having in mind I’m using relatively common nginx
configuration/apache backend, once these changes are applied to
the stable release they will probably affect many others?

This change won’t be applied to stable. It was initially intended
to go to current only, see patch discussion here:

http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001620.html

Actually, I even consider backing it out in current, as
configuration in question is quite common and I don’t really like
both of the workarounds. I don’t like previous behaviour either,
but the change seems to be more drastic than it was originally
expected.

Maxim D.

Maxim_D · December 29, 2011, 1:23am

Understood,

Can I still use the ‘quick fix’ configuration (passing $request_uri to
the backend) with older (and newer) nginx releases? Or should I revert
back to older configuration when updating?

Regards,

Boyko

Maxim_D · December 28, 2011, 11:14am

Hello!

On Tue, Dec 27, 2011 at 06:09:50PM +0200, Boyko Y. wrote:

nginx 1.1.12 behaves differently compared to nginx 1.1.11 on my
setup which I’ll try to explain below.

[…]

While my configs may not be optimized or may even be wrong, they
were interpreted differently by every nginx version other than
1.1.12. Not sure if this is something I have to fix by changing
my configs?

(cc’d back to list)

Ok, so basically your config (simplified) is as follows:

location / {
    index index.php;
}

location ~ \.php$ {
    proxy_pass http://backend;
}

With 1.1.12 proxy_pass without URI component always uses modified
URI after internal redirects, and as a result “/index.php” request
is passed to upstream instead of “/” previously (as index module
does an internal redirection, see [1]).

Apparently your backend doesn’t like this and returns 302 in an
attempt to normalize the URI.

Quick fix is to use something like

location ~ \.php$ {
    proxy_pass http://backend$request_uri;
}

to ensure original request uri is passed to upstream.
Alternatively, you may use something like

location ~ (\.php|/)$ {
    proxy_pass http://backend;
}

[1]
http://www.nginx.org/en/docs/http/request_processing.html#simple_php_site_configuration

Maxim D.

Maxim_D · December 29, 2011, 2:16am

Hello!

On Wed, Dec 28, 2011 at 09:19:45AM +0200, Boyko Y. wrote:

Understood,

Can I still use the ‘quick fix’ configuration (passing
$request_uri to the backend) with older (and newer) nginx
releases? Or should I revert back to older configuration when
updating?

Both workarounds will work ok.

Maxim D.

Maxim_D · December 29, 2011, 8:09am

On Dec 29, 2011, at 9:04 AM, agentzh wrote:

On Mon, Dec 26, 2011 at 11:48 PM, Maxim D. [email protected] wrote:

Changes with nginx 1.1.12 26 Dec 2011

It seems that the following line in nginx.h is incorrect for this release?

#define nginx_version 1001011

I think it should be 1001012 instead here

That’s right. It’ll be alright in 1.1.13 (in a couple of weeks),
apologies.

Maxim_D · December 29, 2011, 6:04am

On Mon, Dec 26, 2011 at 11:48 PM, Maxim D. [email protected]
wrote:

Changes with nginx 1.1.12 26 Dec 2011

It seems that the following line in nginx.h is incorrect for this
release?

#define nginx_version 1001011

I think it should be 1001012 instead here

Regards,
-agentzh

Maxim_D · December 31, 2011, 1:41pm

On 29 Dez 2011 07h08 WET, [email protected] wrote:

#define nginx_version 1001011

I think it should be 1001012 instead here

That’s right. It’ll be alright in 1.1.13 (in a couple of weeks),
apologies.

Trivial patch attached.

— appa

Nginx-1.1.12

Thank you, Kevin

Thank you,
Kevin