Still confused with try_files

for a site with multiple “if file does not exist, use this master
controller file” like wordpress, drupal, etc, does a config like this
make sense?

because right now, it doesn’t.

the /blog one does, but the /second one doesn.t

server {
listen 80;
server_name proto.foo.net;
index index.php index.html;
root /home/proto/web/proto.foo.net;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
location /blog {
error_page 404 = /wordpress/index.php?q=$request_uri;
}
location /second {
try_files $uri $uri/
/second/controller.php?slug=$request_uri;
}
location ~ .php$ {
fastcgi_pass 127.0.0.1:11020;
}
}

2009/03/16 21:40:29 [error] 29669#0: *638 rewrite or internal
redirection cycle while internal redirect to
“/second/controller.php?slug=/second/contro”, client: 123.5.226.17,
server: proto.foo.net, request: “GET /second/contro HTTP/1.1”, host:
proto.mikehost.net

I really want to use try_files as I believe it is better than using
error_page 404 and if ( !-e $request_filename) type stuff, right? All
I need is to understand the routing better and I’ll be on my way. :slight_smile:

I guess it makes sense about the internal redirection cycle but how
else can I route only requests to the prefix of /second to that
application’s controller?

Thanks.

On Mon, Mar 16, 2009 at 09:44:30PM -0700, mike wrote:

    server_name proto.foo.net;
    location ~ \.php$ {

I really want to use try_files as I believe it is better than using
error_page 404 and if ( !-e $request_filename) type stuff, right? All
I need is to understand the routing better and I’ll be on my way. :slight_smile:

I guess it makes sense about the internal redirection cycle but how
else can I route only requests to the prefix of /second to that
application’s controller?

The attached patch should fix the bug.

2009/3/19 Igor S. [email protected]:

The attached patch should fix the bug.

I tried this patch together with the 0.6.3.5 try_files patch and I get
the following log message now:
2009/03/19 14:30:10 [error] 2795#0: *43 rewrite or internal
redirection cycle while internal redirect to
“/members/index.php?q=/members/user/register”, client: 89.236.30.115,
server: themansion.mine.nu, request: “GET /members/user/register
HTTP/1.1”, host: “themansion.mine.nu”

It looks like the $request_uri; contains the directory (/members/).
How can this be removed? Drupal expects a redirect to
“/members/index.php?q=user/register”.

My config file is available here:
http://www.giuntilabs.net/files/nginx/nginx.conf

thanks,
Otto

On Thu, Mar 19, 2009 at 02:54:53PM +0100, Otto Bretz wrote:

HTTP/1.1", host: “themansion.mine.nu”

It looks like the $request_uri; contains the directory (/members/).
How can this be removed? Drupal expects a redirect to
“/members/index.php?q=user/register”.

My config file is available here:
http://www.giuntilabs.net/files/nginx/nginx.conf

You can not apply the patch against 0.6.35: there are missed parts, that
availabe in 0.7 only.

The attached patch includes all try_files functionality and bugfixes.

2009/3/19 Igor S. [email protected]:

server {
        try_files $uri $uri/ /second/controller.php?slug=$request_uri;
server: proto.foo.net, request: “GET /second/contro HTTP/1.1”, host:
The attached patch should fix the bug.
Seems to work now.

Approved: patch.try_files.0.7.43

:slight_smile:

2009/3/19 Igor S. [email protected]:

Should I try with a debug build?

Yes, as I could not reproduce the issue.

I’ve posted the log here:
http://www.giuntilabs.net/files/nginx/notworking.log

As far as I can tell drupal sends a 404 message since it cannot handle
“?q=/members/user/register”. It expects “?q=user/register”.

thanks,
Otto

ps. config is http://www.giuntilabs.net/files/nginx/nginx.conf

On Fri, Mar 20, 2009 at 12:38:45PM +0100, Otto Bretz wrote:

2009/3/19 Igor S. [email protected]:

Should I try with a debug build?

Yes, as I could not reproduce the issue.

I’ve posted the log here: http://www.giuntilabs.net/files/nginx/notworking.log

As far as I can tell drupal sends a 404 message since it cannot handle
“?q=/members/user/register”. It expects “?q=user/register”.

Currently, this is available in 0.7.43 only with location regex
captures:

    location ~ \.php$ {
        fastcgi_pass   ...
    }

    location ~^/members(.+)$ {
        try_files  $uri  $uri/ 

/members/index.php?q=$1$is_args$args;
}

I’m not sure is it easy possible to backport location regex captures
to 0.6.x, since there are many changes in location code in 0.7.x.

2009/3/20 Igor S. [email protected]:

I’m not sure is it easy possible to backport location regex captures
to 0.6.x, since there are many changes in location code in 0.7.x.

No problem, it’s not that urgent for me. I can use 0.7.x for a while.

Thanks for you quick replies.

/Otto

2009/3/19 Igor S. [email protected]:

On Thu, Mar 19, 2009 at 02:54:53PM +0100, Otto Bretz wrote:
The attached patch includes all try_files functionality and bugfixes.

Thanks, that patch works better but something still seems to be wrong
with my setup.

If I try to access http://themansion.mine.nu/members/user/register now
I get a 404. Same config as before [1]. Should I try with a debug
build?

/Otto

[1] http://www.giuntilabs.net/files/nginx/nginx.conf