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.