Passing request directly to named location

Server NGINX
1

Hello all.

I currently have my php set up as so

...
  location ~ \..*/.*\.php$ {
    return 403;
  }
  location ~* ^.+\.php$ {
    try_files $uri/fail @proxy;
  }
  location @proxy {
    proxy pass etc
  }
  location
some-location-that-sometimes-needs-rewriting-in-apache-htaccess {
    try_files $uri $uri/ @proxy;
  }
...

Is there a way where when a ‘.php’ file is equested, I just pass the
request to the ‘@proxy’ location.

Now I have to use ‘$uri/fail’ (a location that will never be found) so
that it will fail and then go to the ‘@proxy’ location.

I see the time spent determining that ‘$uri/fail’ does not exist to be a
waste but I can’t do ‘try_files @proxy’ directly.

An option at also works is …

...
  location ~* ^.+\.php$ {
    error_page 403 = @proxy;
    return 403;
  }
...

Just wondering which is more efficient.

Thanks

Posted at Nginx Forum:

2

On Fri, Feb 11, 2011 at 05:08:40AM -0500, Dayo wrote:

try_files $uri/fail @proxy;

...
>   location ~* ^.+\.php$ {
>     error_page 403 = @proxy;
>     return 403;
>   }
> ...

Just wondering which is more efficient.

The one and single efficient and scaleable way is to define explictly
how do you want to handle location, that is:

location ~* ^.+.php$ {
# BTW, what does this hack mean ???
location ~ ../..php$ {
return 403;
}

 proxy_pass  ...

}

The lesser you have dependences, the lesser you will have maintence
issues in future. Yes, you have to write more, but you see what
how exactly this location is handled. If you ever need to change
proxied server address, your favourite editor with find/replace
functionality is your friend.

–
Igor S.
http://sysoev.ru/en/

3

one place and not run the risk of missing stuff out.
I heard this “centralise” mantra many times. Believe me, it works until
your configuration fits on screen or two. When it grows, every, note,
EVERY configuration modification becames investigation of
configuration dependences. I have an configuraiton with 180 locaitons.
When I need to add some functionality, I simply add location and
that is all. I do not look through whole 90K file.

Why ? Because I

  1. use only locations without regex.
  2. do not use rewrite’s at all.

If I need to change a proxied server name or something else, I use
simple
find/replace in VIM. This is very easy, it’s much easy than
investigation
of configuration dependences on every change.

So in terms of the try files and error page options, can you advise
which is better … taking note of what you said about doing each proxy
pass every time?

error_page is faster because it does not make syscall.

–
Igor S.
http://sysoev.ru/en/

4

Igor S. Wrote:

that is all. I do not look through whole 90K file.
of configuration dependences on every change.
Noted. I used to have them like you have but with time, I have found
having stuff centralised more convenient for me.
That is the great thing about this little webserver you have written …
it allows tons of options and with agentzh and the other fellas in
Shanghai coming out with all sorts of crazy modules, it is just mouth
watering.

Would be nice if some of the stuff coming out of Shanghai could be
pushed into the core.

BTW, please consider ‘proxy_no_cache_null’ and ‘proxy_cache_bypass_null’
options to complement the ‘proxy_no_cache’ and ‘proxy_cache_bypass’
options. That is, they should not cache / bypass cache for requests
where the passed variables are null. I use the current options to bypass
cache for logged in users after checking a cookie but it is difficult to
bypass cache based on absence of cookie.

Anyway, this is deviating and I managed to use the lua module from
agentzh (with his help) to do this.

So in terms of the try files and error page
options, can you advise
which is better … taking note of what you said
about doing each proxy
pass every time?

error_page is faster because it does not make
syscall.

Thanks. I thought that might be the case.

Posted at Nginx Forum:

5

Igor S. Wrote:

}
try_files $uri $uri/ @proxy;
that it will fail and then go to the ‘@proxy’
…
to define explictly
how do you want to handle location, that is:

location ~* ^.+.php$ {
# BTW, what does this hack mean ???
location ~ ../..php$ {
return 403;
}
Got it from here:
Re: nginx 0day exploit for nginx + fastcgi PHP
Not using fastcgi at present but wanted to stop any ‘.jpg/.php’ type
attempts
proxied server address, your favourite editor with
find/replace
functionality is your friend.
Thanks but I prefer to centralise things so that I only have to edit in
one place and not run the risk of missing stuff out.
So in terms of the try files and error page options, can you advise
which is better … taking note of what you said about doing each proxy
pass every time?

Thanks

Posted at Nginx Forum:

6

Dayo Wrote:

That is the great thing about this little
webserver you have written … it allows tons of
options and with agentzh and the other fellas in
Shanghai coming out with all sorts of crazy
modules, it is just mouth watering.

Would be nice if some of the stuff coming out of
Shanghai could be pushed into the core.

Looks like someone is on my wavelength.

Posted at Nginx Forum: