15 messages in ru.sysoev.nginxRe: php and locations with regex (rou...| From | Sent On | Attachments |
|---|---|---|
| Alejandro Vartabedian | Oct 23, 2007 3:43 am | |
| Alejandro Vartabedian | Oct 23, 2007 7:16 am | |
| Igor Sysoev | Oct 23, 2007 7:29 am | |
| Maxim Dounin | Oct 23, 2007 7:33 am | |
| Alejandro Vartabedian | Oct 23, 2007 7:42 am | |
| Alejandro Vartabedian | Oct 23, 2007 7:44 am | |
| Alejandro Vartabedian | Oct 23, 2007 8:37 am | |
| Grzegorz Nosek | Oct 23, 2007 8:43 am | |
| Alejandro Vartabedian | Oct 23, 2007 9:25 am | |
| Igor Sysoev | Oct 23, 2007 9:33 am | |
| Alejandro Vartabedian | Oct 23, 2007 10:55 am | |
| Grzegorz Nosek | Oct 24, 2007 1:31 am | |
| Igor Sysoev | Oct 24, 2007 3:00 am | |
| Igor Sysoev | Oct 24, 2007 3:23 am | |
| Alejandro Vartabedian | Oct 24, 2007 5:40 am |
| Subject: | Re: php and locations with regex (round 2) | |
|---|---|---|
| From: | Igor Sysoev (is-G...@public.gmane.org) | |
| Date: | Oct 24, 2007 3:00:15 am | |
| List: | ru.sysoev.nginx | |
On Wed, Oct 24, 2007 at 10:31:48AM +0200, Grzegorz Nosek wrote:
2007/10/23, Igor Sysoev <is-G...@public.gmane.org>:
You may use:
location ~ \.php$ { fastcgi_pass ... ... }
location ~ ^/(app1|app2)/ { root ... ... }
This gets ugly quickly if you decide one day to e.g. pass different php files to different fastcgi backends (running under different users or something). Also, if I'm right, errors while serving php pages come from the first location, so requests for /app1/nonexistent.php and /app1/nonexistent.jpg may result in different error handling.
I agree. I personally prefer to avoid such general locations and try to describe more detailed locations. It seems redudant for simple sites with several locations, but my practice shows that sites usually grow and these general locations become cumbersome.
It's better do not use "if". Try to route request via locations only. If you want to pass non-existent files to FastCGI/proxy it's better to use:
location / { root ... error_page 404 = @fallback; }
location @fallback { fastcgi_pass ... ... }
Why? Because the configuration inside if blocks isn't really merged with its parent config but overwritten (AFAIK, that's what vanilla nginx does; my patchset fixes that, at least for cases I care about)?
The configuration inside if blocks is actually merged, but not for all directives.
Or is there another reason? Routing dynamic content via error pages seems hackish to me -- an if block inside location looks more natural (again, IMHO).
if block is hack inside nginx and this is the reason.
Oh, and BTW -- given that my nginx patchset merges the configs, is there any (other) reason to disallow certain directives inside if blocks (those allowed in location, of course)?
Current if/rewite is ugly and I will change it, thus I do not enable many directives inside if block.
-- Igor Sysoev http://sysoev.ru/en/