I have a staging site that I test anything relating to the website
before we deploy. I have an nginx config that I also test with for this
staging site.

I wanted to rewrite a uri segment where a section of the site changed
names.

example.com/old/page1
/old/page2

example.com/new/page1
/new/page2

I added the following rewrite, which works perfectly on the staging
site.

location /old {
rewrite ^/old/? /new/$1 permanent;
}

when I added this to the live nginx config, the rewrite works, but only
sort of:

what I want:
example.com/old/page1 --> example.com/new/page1

what I get:
example.com/old/page1 --> example.com/new

It's fine for now, but I don't know why the exact config would work
different.

The live nginx config is different than the staging, but only in that it
includes SSL info. This may be the problem, but I'm not sure why.

Thank you in advance for any suggestions and/or answers.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,227464,227464#msg-227464

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

On Tue, Jun 12, 2012 at 10:47:10AM -0400, caleboconnell wrote:

Hi there,

> location /old {
> rewrite ^/old/? /new/$1 permanent;
> }

What do you think $1 is set to here?

(Usually, it is "the last thing matched". So usually, it is worth making
sure that you match something immediately before using it.)

> what I want:
> example.com/old/page1 --> example.com/new/page1
>
> what I get:
> example.com/old/page1 --> example.com/new

http://nginx.org/r/rewrite

"regex" can include things inside parentheses, which are then available
as ${number} in "replacement".

location /old/ {
rewrite ^/old/(.*) /new/$1 permanent;
}

will probably do what you want; but read about the question mark, in
case it matters.

> It's fine for now, but I don't know why the exact config would work
> different.

Usually, the same config works the same way. If you've found a case where
that isn't the case, it may be worth investigating. But it is potentially
the *whole* config that matters here, where you use $1 without showing
where it is set.

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

That's exactly what I thought, but when I used (.*) at the end and used
the $1 I kept getting 404. When I made it the way it is now, it worked
on my staging site as expected but not on my live site.

I can confirm that on neither site, the following does not work (404
error):

location /old {
rewrite ^/old/(.*)$ /new/$1 permanent;
}

the following will redirect anything from old to the landing page for
the new section

location /old {
rewrite ^/old? /new permanent;
}


here is the current config, with prior rewrites before this location
block:

location / {
index index.php;
try_files $uri $uri/ @ee;
}

location @ee {
rewrite ^(.*) /index.php?/$1 last;
}

location /old {
rewrite ^/old? /new permanent;
}

I tired to use (.*) and $2 in hopes that the prior $1 wasn't breaking
it. Still no luck.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,227464,227496#msg-227496

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Try to use your regex in the location path too.

location '/old' only catches '/old', not even '/old/' and of course nothing
lie '/old/....'
Then, inside, you rewrite only URI which start with '/old/', so *in fine*,
nothing will be ever redirected.

The machine does precisely what you asked it to do.
---
*B. R.*


On Wed, Jun 13, 2012 at 10:31 AM, caleboconnell <[email protected]>wrote:

> That's exactly what I thought, but when I used (.*) at the end and used
> the $1 I kept getting 404. When I made it the way it is now, it worked
> on my staging site as expected but not on my live site.
>
> I can confirm that on neither site, the following does not work (404
> error):
>
> location /old {
> rewrite ^/old/(.*)$ /new/$1 permanent;
> }
>
> the following will redirect anything from old to the landing page for
> the new section
>
> location /old {
> rewrite ^/old? /new permanent;
> }
>
>
> here is the current config, with prior rewrites before this location
> block:
>
> location / {
> index index.php;
> try_files $uri $uri/ @ee;
> }
>
> location @ee {
> rewrite ^(.*) /index.php?/$1 last;
> }
>
> location /old {
> rewrite ^/old? /new permanent;
> }
>
> I tired to use (.*) and $2 in hopes that the prior $1 wasn't breaking
> it. Still no luck.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,227464,227496#msg-227496
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

The following worked. Thanks for helping me with this. Hopefully it
answers another newbie's question someday.

location ^~ /old {
rewrite ^/old(.*)$ /new$1 permanent;
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,227464,227499#msg-227499

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

On Wed, Jun 13, 2012 at 10:31:02AM -0400, caleboconnell wrote:

Hi there,

you have a working set up now, so all is good.

But still, I am very surprised that

> location /old {
> rewrite ^/old/(.*)$ /new/$1 permanent;
> }

will not cause a redirection for any request that starts /old/, when
replacing that location with

> location /old {
> rewrite ^/old? /new permanent;
> }

will lead to the expected redirection.

The solution you found was to change the location definition to avoid
trying any regex locations. That suggests that you had other regex
locations which were being matched instead of the ones above. But
independent of that, the above two locations should redirect almost all
of the same requests (all bar exactly "/old") -- so if the rest of the
configuration didn't change in between the two tests, you have found
something odd.

> here is the current config, with prior rewrites before this location
> block:

For information: because one request is handled by one location, the
order of location blocks within the config file is not relevant (apart
from regex ones).

Which just means that "the most recent match" may not be from the location
block a few lines earlier in the config file.

All the best,

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx