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.
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.
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.
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.
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.
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.