Ok, I've finally had a breakthrough, but that has spawned a new question.
I encountered an old post on this list regarding RegEx behavior and the
response was to "split up each RegEx into a unique rule"... I did this,
and my 500's immediately turned into 404's... so *something* happened.
But I still couldn't get my RegEx to appear to latch on, or forcibly
make any changes in the log.
So I added a new rule, 2nd from the top (1st rule is an Extensions php
non-final rule), so as to avoid any per-directory parsing...
This one is basically:
Directory /
Redirection- Internal: .* Substitution: FOO
When I hit www.site.com/test
The logs display:
"GET /test HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
... about 41 times in total (I suspect the length of my timeout)
First: My RegEx redirection works.
Second: If I understand this resultant behavior, my redirection causes
another lookup? Which causes another lookup which causes another lookup
ad nausea until Cherokee forces its timeout (due to the ambiguous nature
of the ".*" RegEx)?
That would make perfect sense to me.
Now, what then confuses me- I change my request to the following:
www.site.com/test/alpha
I'd expect:
"GET /test/alpha HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
"GET /FOO HTTP/1.1" 301 638 "-"
...
But instead the logs display:
"GET /test/alpha HTTP/1.1" 301 638 "-"
"GET /test/FOO HTTP/1.1" 301 638 "-"
"GET /test/FOO HTTP/1.1" 301 638 "-"
...
Further directory descents verify that ONLY the LAST directory is
being altered, where I was expecting the ENTIRE string being altered.
Is ".*" not a greedy RegEx to Cherokee? Am I still looking at this
incorrectly?
I feel simultaneously successful and baffled.
-Matthew
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
