Hi there,

I used to have this in Apache (from http://stackoverflow.com/questions/476456/why-does-rewriterule-page-page-php-l-match-site-com-page)
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule // /%1%3 [L,NE,R=301]

In Nginx, it is simply
rewrite ^/(([^/\ ]+/)*)/+([^\ ]*) /$1$3? permanent;

It used to work in Apache and I tested the new regex with http://www.regextester.com/ and it works.
However, I can't get it to work. When i request www.mydomain.com//sony it does not issue a 301 to the client to request www.mydoamin.com/sony. Nginx just continues to pass the original request to the backend.

Thank you for your help,
Richard

you need to specify full URI for redirection

rewrite ^/(([^/\ ]+/)*)/+([^\ ]*) http://yoursitehere.com/$1$3? permanent;

hi edogawaconan,

that's what the documentation says as well but it didn't work. in fact, i was able to prove that it was not necessary (to add the domain) because the following redirects /foobar to /barfoo

rewrite ^/(foo)(bar)$ /$2$1 permanent;

the rewrite works for simple cases like foobar, so is it possible that "complicated" regex parsing in nginx isn't working?

thank you,
richard

Figured out why it wasn't working. The answer was in the proxy_pass directive.

During the working:

* two or by more slashes are converted into one slash: "//" -- "/";
* references to the current directory are removed: "/./" -- "/";
* references to the previous catalog are removed: "/dir /../" -- "/".

the matching for rewrites is performed against the CLEANED request. ie, it is performed against $uri NOT $request_uri.

So my redirect never happened because it never matched. I should be thankful there is some documentation but it really needs to be better. Now that I intuitively understand how rewrite and proxy_pass works, I am able to understand the sometimes cryptic translations. Again, I will be grateful that I can leverage open source and didn't have to write my own proxy/web server from scratch.