Rewrite rule

Server NGINX
1

There has been a change of behaviour on the rewrite rule between version
0.7.1 and higher… I don’t know if it’s a bug or a correction !

You can view a configuration type here : http://pastebin.com/f49df278c
And the beginning of the debug file : http://pastebin.com/f547dc485

The end:

Version 0.7.1 (good behaviour)
2008/07/19 14:17:07 [debug] 31892#0: 1 http script regex:
"^/fallback(.)$"
2008/07/19 14:17:07 [debug] 31892#0: *1 http script capture:
“/users/test”
2008/07/19 14:17:07 [debug] 31892#0: *1 http script regex end
2008/07/19 14:17:07 [debug] 31892#0: *1 post rewrite phase: 3
2008/07/19 14:17:07 [debug] 31892#0: *1 uri changes: 10
2008/07/19 14:17:07 [debug] 31892#0: *1 using configuration “/fallback/”
2008/07/19 14:17:07 [debug] 31892#0: *1 http cl:-1 max:1048576
2008/07/19 14:17:07 [debug] 31892#0: *1 generic phase: 2

Version 0.7.6
2008/07/19 14:24:02 [debug] 32178#0: 1 http script regex:
"^/fallback(.)$"
2008/07/19 14:24:02 [debug] 32178#0: *1 http script capture:
“/users/test”
2008/07/19 14:24:02 [debug] 32178#0: *1 http script regex end
2008/07/19 14:24:02 [debug] 32178#0: *1 post rewrite phase: 3
2008/07/19 14:24:02 [debug] 32178#0: *1 uri changes: 10
2008/07/19 14:24:02 [debug] 32178#0: *1 test location: “/”
2008/07/19 14:24:02 [debug] 32178#0: *1 test location: “fallback/”
2008/07/19 14:24:02 [debug] 32178#0: *1 test location: “/dynamic/”
2008/07/19 14:24:02 [debug] 32178#0: *1 using configuration “/”
2008/07/19 14:24:02 [debug] 32178#0: *1 http cl:-1 max:1048576
2008/07/19 14:24:02 [debug] 32178#0: *1 generic phase: 2

It should not recheck the locations…

Thanks

2

Hello!

On Sat, Jul 19, 2008 at 02:53:57PM +0200, Chavelle V. wrote:

“^/fallback(.*)$”
2008/07/19 14:17:07 [debug] 31892#0: *1 http script capture:
“/users/test”
2008/07/19 14:17:07 [debug] 31892#0: *1 http script regex end
2008/07/19 14:17:07 [debug] 31892#0: *1 post rewrite phase: 3
2008/07/19 14:17:07 [debug] 31892#0: *1 uri changes: 10
2008/07/19 14:17:07 [debug] 31892#0: *1 using configuration “/fallback/”
2008/07/19 14:17:07 [debug] 31892#0: *1 http cl:-1 max:1048576
2008/07/19 14:17:07 [debug] 31892#0: *1 generic phase: 2

This isn’t correct behaviour, it’s bug introduced in 0.7.1 and
fixed in 0.7.2. Your rewrite directive in location /fallback/
changed the request uri, but nginx failed to do correct search of
new location to use.

2008/07/19 14:24:02 [debug] 32178#0: *1 test location: “/dynamic/”
2008/07/19 14:24:02 [debug] 32178#0: *1 using configuration “/”
2008/07/19 14:24:02 [debug] 32178#0: *1 http cl:-1 max:1048576
2008/07/19 14:24:02 [debug] 32178#0: *1 generic phase: 2

It should not recheck the locations…

It should with ‘last’ flag in rewrite, and shouldn’t with ‘break’
flag. The default is ‘last’, and since you haven’t specified
‘break’ in your config - it should.

Solution is obvious:

  •       rewrite  ^/fallback(.*)$ $1;

  •       rewrite  ^/fallback(.*)$ $1 break;

See http://wiki.codemongers.com/NginxHttpRewriteModule#rewrite for
details.

And, BTW, I think you should use named locations instead. Just
write something like:

 location / {
     error_page 404  = @fallback;
     ...
 }
 location @fallback {
     proxy_pass ...;
     ...
 }

You don’t actually need all this rewrite stuff. :slight_smile:

Maxim D.

3

Maxim D. wrote:

You don’t actually need all this rewrite stuff. :slight_smile:

Maxim D.

Thank you for these advices. It really help me :slight_smile:

Could you see SSI with MEMCACHED down - NGINX - Ruby-Forum topic.
Maybe that is still my fault :stuck_out_tongue:

4

Hello!

On Sun, Jul 20, 2008 at 11:31:20PM +0200, Chavelle V. wrote:

Maxim D. wrote:

You don’t actually need all this rewrite stuff. :slight_smile:

Maxim D.

Thank you for these advices. It really help me :slight_smile:

No problem.

Could you see SSI with MEMCACHED down - NGINX - Ruby-Forum topic.
Maybe that is still my fault :stuck_out_tongue:

I’m not really understand what you are trying to achieve, but I
belive you problem is your backend’s Etag header, which is used by
your browser to check freshness of the page. Backend replies 304
Not Modified - and nginx’s SSI has no chance to modify page.

Try the following:

proxy_hide_header Etag;

This will hide Etag header from responses sent to clients, and
probably will resolve your issue. Of course you need to clear
browser cache once again to remove old version of the page with
Etag.

See
http://wiki.codemongers.com/NginxHttpProxyModule#proxy_hide_header
for details.

Maxim D.

5

Maxim D. wrote:

Try the following:

proxy_hide_header Etag;

You correct my problem ! Many thanks again…

6

Hi Maxim,

On 20 Jul 2008, at 20:58, Maxim D. wrote:

}

You don’t actually need all this rewrite stuff. :slight_smile:

I’ve tried several times to use named locations in exactly this
fashion with PHP/FastCGI backends, but experienced show-stopping
problems using POST. POSTing data through these locations just
wouldn’t work properly, either throwing 405 errors or, after applying
some configuration changes (static post), simply hanging.

I posted to the list a couple of times but didn’t get any response -
the most recent was “Posting to FastCGI in named locations” on 15 May
(http://article.gmane.org/gmane.comp.web.nginx.english/5036
). It’s frustrating because I can see how much better the named
locations are but have been unable to use them because of this problem.

Do you have any idea what might be the cause?

Many thanks,
Igor