You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Michael Douglass <mi...@texas.net> on 1998/01/09 23:22:15 UTC
problem with mod_rewrite.c
Okay, I've dug down through source code tyring to find the problem here--and
actually I'm vaguely following what mod_rewrite.c (shipping with 1.2.5) is
doing; but not enough to make perfect sense out of it all. Here is an
explanation of my problem:
Let's say I have this rule
RewriteCond %{HTTP_HOST} ^.+\.dink\.net$
This will match any host with any number of characters ending in
".dink.net". And it does, the rule works perfectly... Unless I try
to use a directory and not put that infamous trailing slash--oh, and
I've tried all the rules for adding slashes, that's _not_ the problem.
>From all approaches, and from spending more time than I cared to pulling
on my hair, it appears that either the HTTP_HOST is being ignored when
there is no trailing /, or something else is going funny.
Oh, also, from the rewrite log, you can see both requests for the same
directory (one from the browser with the / and one without) initing with
the _same_ URI.
ie:
>From web browser request where trailing slash was left of (ie.: '/uo')
- - [...] [...][...] (2) init rewrite engine with requested uri /uo/
>From web browser request where trailing slash was included of (ie.: '/uo/')
- - [...] [...][...] (2) init rewrite engine with requested uri /uo/
Same URI being passed into it, one follows through with the rewrite
condition matching, the other doesn't... It's blowing my mind.
-- on another note:
Oh, and no matter what some people may say about "treating your 'users'
with care"--as if to imply that you don't treat them with care--ignore
the blast as out-of-line. If anything, I'm more than happy with this
project and am glad to be a 'user' of sorts; which in this same context,
knowing M$ quality of service, I am really concerned about stronghold. :(
--
Michael Douglass
Texas Networking, Inc.
<tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady
Re: problem with mod_rewrite.c
Posted by Michael Douglass <mi...@texas.net>.
On Fri, Jan 09, 1998 at 03:39:43PM -0700, Marc Slemko said:
> Read the thread from the other week about implementing virtual servers
> using this. It uses the Servername and requires code changes to
> the construct_url area to use the Host: header if present.
Thanks for the pointer Marc, I really respect all your work with
Apache, but I've read the thread and don't really see talk of
construct_url (unless you are talking about a thread that I no
longer have--but doubtful). My post, as far as I can tell, is
pointing out a very legitimate bug; The following two URLs produce
the same URI being inited into mod_rewrite:
http://blah.dink.net/test/
http://blah.dink.net/test
The URI that mod_rewrite reports as being inited into the engine is
"/test/" for both URLs.
The first one goes through, hits the condition of matching
/^.+\.dink\.net/ and does the rest of the rule substitutions; The
second one, however, does not match the same condition when it
should, no? That is what I'm writing about.
Now, am I missing the point, and the second URL really need the code
modifictation you are talking about to construct_url? If so, why? They
should both still be getting sent to mod_rewrite with the %{HTTP_HOST}
of 'blah.dink.net' and should both exit with the same file results since
both go in with the same strings...
Or am I really confused?
--
Michael Douglass
Texas Networking, Inc.
<tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady
Re: problem with mod_rewrite.c
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 9 Jan 1998, Michael Douglass wrote:
> Okay, I've dug down through source code tyring to find the problem here--and
> actually I'm vaguely following what mod_rewrite.c (shipping with 1.2.5) is
> doing; but not enough to make perfect sense out of it all. Here is an
> explanation of my problem:
>
> Let's say I have this rule
>
> RewriteCond %{HTTP_HOST} ^.+\.dink\.net$
>
> This will match any host with any number of characters ending in
> ".dink.net". And it does, the rule works perfectly... Unless I try
> to use a directory and not put that infamous trailing slash--oh, and
> I've tried all the rules for adding slashes, that's _not_ the problem.
Read the thread from the other week about implementing virtual servers
using this. It uses the Servername and requires code changes to
the construct_url area to use the Host: header if present.