URI pattern baffling problem

Hi,

I am trying to work out a regular expression. What I am looking for is
to
redirect any request that does not match a specific URI pattern.

The exact pattern is documents/{VAR1}/pages/{VAR2}/items/{VAR3} where
{VAR1} /{VAR2} /{VAR3} is a random chain of 36 characters made of A-Z,
a-z,
0-9 and (hyphen). Text is not case sensitive and the position of
hyphens
is fixed. Would be great if I could also work trailing double-slash.

So far what I have generated is:

if ($request_uri !~*
“^documents/([a-z0-9-]{36})pages/([a-z0-9-]{36})items/([a-z0-9-]{36})$”
)
{
rewrite ^ http://www.google.com/ permanent;
}

Regular expression is not really my cup of tea, so any hint is most
welcome!

Gregory

On 2/7/2011 5:43 PM, Gregory wrote:

I am trying to work out a regular expression.What I am looking for is to
redirect any request that does not match a specific URI pattern.

May be try to mention correct patterns as locations, and after that this
rewrite rule?

Also:

“^documents/([a-z0-9-]{36})pages/([a-z0-9-]{36})items/([a-z0-9-]{36})$”

missed some slashes and capitals.

“^documents/([A-z0-9-]{36})/pages/([A-z0-9-]{36})/items/([A-z0-9-]{36})$”.

Cheers.

Firstly you are missing slashes after each var/regex

Sent from my iPod

Because, as me and Splitice mentioned before, your regexp is not correct
(at least I cannot see slashes between hash and pages). Fix it.

Yes, my bad when I pasted the expression. My current rule is:

    if ($request_uri !~*

“^documents/([A-Z0-9-]{36})pages/([A-Z0-9-]{36})items/([A-Z0-9-]{36})” )
{
rewrite ^ http://www.google.com/ permanent;
}

But it never matches anyway. If the expression match, I should just
continue, otherwise just redirect to (google) for instance.

Gregory

2011/2/7 Splitice [email protected]

Ok you are right, I did also copied it wrong, anyway, this one don’t
work
any better anyway:

if ($request_uri !~*
“^documents/([A-Z0-9-]{36})/pages/([A-Z0-9-]{36})/items/([A-Z0-9-]{36})”
) {
rewrite ^ http://www.google.com/ permanent;
}

Which does contain all slashes. The expression never match. I am trying
with
the following URL
http://www.domain.tld/documents/C49775E0-4C80-0001-22B1-13B052801E5C/pages/C4977880-4C80-0001-22B1-13B052801E5C/items/C4977880-4C80-0001-22B1-13B052801E5C

Gregory

2011/2/8 Vitaly T. [email protected]

On 8 Fev 2011 09h41 WET, [email protected] wrote:

http://www.domain.tld/documents/C49775E0-4C80-0001-22B1-13B052801E5C/pages/C4977880-4C80-0001-22B1-13B052801E5C/items/C4977880-4C80-0001-22B1-13B052801E5C

Try:
“^/documents/(?:[A-Z0-9-]{36})/pages/(?:[A-Z0-9-]{36})/items/(?:[A-Z0-9-]{36}”

It’s working for me in cl-ppcre with the URI you gave as an example.

— appa

On Tue, Feb 08, 2011 at 11:55:27AM +0100, Gregory Agerba wrote:

Thanks Antonio, now that worked.

You should think not in negative way:

if ($request_uri !~* "^/documents/(?:[A… ") {
{
rewrite ^ http://www.google.com/ permanent;
}

but in positive way:

location ~* "^/documents/(?:[A… " {

}

location / {
rewrite ^ http://www.google.com/ permanent;
}

  • Gregory

2011/2/8 Antnio P. P. Almeida [email protected]

Try:
“^/documents/(?:[A-Z0-9-]{36})/pages/(?:[A-Z0-9-]{36})/items/(?:[A-Z0-9-]{36}”


Igor S.
http://sysoev.ru/en/

Hi Igor,

Yes, but my rule is only acting as a simple Access Control List which
expect a very special pattern to match and anything else should be
discarded
with an error message/page.

The given pattern is not accessed directly by users, its an application
that send requests to that given URI-pattern and if the pattern doesnt
match (thus in my case it means it’s a valid request), then the request
is
processed further in Passenger.

In my understanding if I am supposed to send the positive matching I
should
forward that somewhere and I will create a loop and this explains why I
do
the opposite here.

Gregory

2011/2/8 Igor S. [email protected]

On 8 Fev 2011 13h11 WET, [email protected] wrote:

location ~* "^/documents/(?:[A… " {

}

location / { rewrite ^ http://www.google.com/ permanent; }

I agree. But the problem stems from the fact that most applications
don’t ever consider the configuration at the server or virtual host
level. Apache has the directory context (.htaccess) so people tend to
make their applications depend on it as much as possible and on the
server or vhost config as little as possible.

Since you cannot define locations in a directory context (.htaccess)
the only solution is to think backwards and hack something revolving
around mod_rewrite.

It’s a deeply rooted habit. It’s not easy to make the transition to
Nginx where there’s no directory context, hence things must be thought
out differently from the outset. But yes we should insist on changing
that habit. Thinking backwards makes Nginx config feel strange and
unnatural.

— appa

On Tue, Feb 08, 2011 at 02:20:00PM +0100, Gregory Agerba wrote:

In my understanding if I am supposed to send the positive matching I should
forward that somewhere and I will create a loop and this explains why I do
the opposite here.

You should enable Passenger inside

location ~* "^/documents/(?:[A… " {

}

rewrite ^ http://www.google.com/ permanent;
}


Igor S.
http://sysoev.ru/en/


nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx


nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx


Igor S.
http://sysoev.ru/en/

Make sense.

For some reasons I thought the “passenger_enabled” parameter could only
be
set in the http or server scope/stanza.

Just notice it can also be set in location and even in an if, now that’s
cool just getting my hands-on experience with Passenger and this duo
together.

Thanks

– Gregory

2011/2/8 Igor S. [email protected]

On Tue, Feb 08, 2011 at 01:24:38PM +0000, Antnio P. P. Almeida wrote:

don’t ever consider the configuration at the server or virtual host
out differently from the outset. But yes we should insist on changing
that habit. Thinking backwards makes Nginx config feel strange and
unnatural.

Any Apache-based application can be configured inside if
it can be configured via .htaccess.
The single reason why .htaccess is so popular is shared hosting.


Igor S.
http://sysoev.ru/en/

Thanks Antonio, now that worked.

  • Gregory

2011/2/8 Antnio P. P. Almeida [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs