5 messages in ru.sysoev.nginxRe: Different FastCGI backend for /su...| From | Sent On | Attachments |
|---|---|---|
| hugo | Aug 11, 2011 1:22 am | |
| Maxim Dounin | Aug 11, 2011 3:45 am | |
| hugo | Aug 11, 2011 5:59 am | |
| hugo | Aug 11, 2011 6:02 am | |
| hugo | Aug 12, 2011 12:33 am |
| Subject: | Re: Different FastCGI backend for /subdir: regex not matching | |
|---|---|---|
| From: | Maxim Dounin (mdou...@mdounin.ru) | |
| Date: | Aug 11, 2011 3:45:24 am | |
| List: | ru.sysoev.nginx | |
Hello!
On Thu, Aug 11, 2011 at 04:22:52AM -0400, hugo wrote:
I have a virtual host, and for a certain subdirectory I want to use another fastcgi backend.
What I have now goes something like: (...) location ~ /subdir/ {
Do you actually want to match prefix here, as opposed to any uri containing "/subdir/" in it? If yes, use
location /subdir/ {
instead. To prevent all other regexp locations from matching under /subdir/ (even if there are no regexp locations in subdir matched) you may also want to use "^~" (no regexp check on match), i.e.
location ^~ /subdir/ {
alias /var/www/otheraccount/public_html/;
# PHP FastCGI location ^~ /subdir\/(.+)\.php {
"^~" means "no regexp check on match", you have to use "~" (regexp location) here instead. And unless you really need captures here for some reason not present in posted config, it's enough to just use \.php pattern here. You may also need "$" anchor to make sure you are matching extension but not some intermediate part of name.
I.e. use
location ~ \.php$ {
here instead.
return 504; include /usr/pkg/etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/othervhost/public_html$fastcgi_script_name;
try_files $uri =502; } }
# PHP FastCGI location ~ \.php {
The same as above: you probably need "$" anchor here.
location ~ \.php$ {
include /usr/pkg/etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9001; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/blah/public_html$fastcgi_script_name;
try_files $uri =403; } }
Ignore the try_files and bogus return, they're in place to try to trace what's happening where.
This is nginx 1.0.4, if it matters.
Basically, the problem is that the last try_files is triggered (I get a 403 requesting /subdir/index.php, and if I change that last try_files to 404 then I get a 404); Therefore I conclude the regex trying to catch php files under /subdir is not effective.
See above. The problem is that you don't have regexp but static string, due to "^~" used.
What would the proper regex be ? I want it to catch /subdir/*.php, /subdir/subsub/*.php, /subdir/s/u/b.php, etc
Recommended pattern is:
location / { ...
location ~ \.php$ { ... } }
location /subdir/ { ...
location ~ \.php$ { ... } }
Note all top-level locations are just normal static strings with prefix match (most specific match wins). Regexp locations are properly isolated in them, and don't interfere with processing of requests in other locations.
On a related note, trying to access www.vhost.local/subdir (no trailing /) results in nginx trying to serve subdir from the original root (ie the alias isn't picked up); It may be a trivial question but I've run
This is because "/subdir" isn't matched by "location /subdir/" (neither by "location ~ /subdir/"), and hence it's processed in some other matching location (usually "location /", or implicit location if you don't have one defined).
into this in the past. What is the correct way to catch both /subdir and /subdir/ requests?
I would recommend using something like
location = /subdir { root ... # or just immediate redirect to /subdir/, e.g # return 301 /subdir/; }
location /subdir/ { root ... }
Note that if you use
location /subdir/ { proxy_pass ... }
nginx will automagically recognize that requests to "/subdir" should be redirected to "/subdir/", and you don't need extra "location = /subdir". This applies only to locations fully handled by backend modules though.
I would very much appreciate a reply on this subject, as I've been struggling with this for hours. Regexes are not my strong point.
Don't use regexp unless you really need to, use normal locations. (This applies even if one have no problems with regexps.)
Maxim Dounin
_______________________________________________ nginx mailing list ngi...@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx