Bug 12902 - DocumentRoot not being appended to URL
Summary: DocumentRoot not being appended to URL
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: 2.0.40
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2002-09-22 12:20 UTC by Rik Arpino
Modified: 2005-03-20 17:06 UTC (History)
3 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Rik Arpino 2002-09-22 12:20:51 UTC
Not the one described in the FAQ btw. Double checked that....!

I cannot get the DocumentRoot prepended to the processed URL *UNLESS* it 
already contains a drive letter (in the RewriteCase). The log results are as 
follows (last few lines only):

With a drive letter:

...(2) local path result: c:/sebastian.tld/www/
...(2) prefixed with document_root to C:/Apache/sitexc:/sebastian.tld/www/
...(1) go-ahead with C:/Apache/sitexc:/sebastian.tld/www/ [OK]

Without drive letter:

...(2) local path result: /sebastian.tld/www/

Without the drive letter already there, logging never reports the 'OK'

Guess this is a problem only effecting Win32 systems.....?

My conditions are in the httpd.conf and were based around the examples in the 
documentation for virtual hosting (this code fails on my system):

RewriteEngine On

RewriteMap lowercase int:tolower

RewriteCond  %{REQUEST_URI}               !^/cgi-bin/
RewriteCond  ${lowercase:%{HTTP_HOST}}	  ^([a-z0-9\_\-]+)\.(.+)$
RewriteRule  ^/(.*)$                      /%2/%1/$1

RewriteCond  %{REQUEST_URI}               ^/cgi-bin/
RewriteCond  ${lowercase:%{HTTP_HOST}}    ^([a-z0-9\_\-]+)\.(.+)$
RewriteRule  ^/(.*)$                      /%2/$1

When Fails HTTP Err 400 is generated....otherwise a 404 is generated.

This example worked fine with 1.3.4

Comment 1 Silvester Erdeg 2002-11-22 20:37:54 UTC
The problem lies function hook_uri2line, beginning on line 1285:

1. the module (I think) wants to make sure that the resulting filename starts
with a slash, but it uses the ap_os_is_path_absolute function. If the filename
does indeed start with a slash this call will succeed on Unix, but it will fail
on Windows because ap_os_is_path_absolute will expect a path starting with D:/
or //machine/share. Hence the "400 Bad Request" error.

2. next the module check if the first part ("the prefix") of the path exists.
This is done using the prefix_stat function which works only on Unixes (it
expects the path to start with a slash!)

I think the first part is unnecessary and that the second part should be based
on core.c (as stated in the comments).
Comment 2 William A. Rowe Jr. 2002-11-23 07:23:07 UTC
  The fact is that "/foo" isn't an absolute path.on Windows.  In all fairness,
  we should still try to work around this.  Note the earlier code was much
  more evil, in that "c:/foo" wasn't recognized as a rooted path.

  The one case I want to avoid is accepting "c:foo" since that path is most
  definately not sufficiently rooted.  So that said, we should try to test
  the APR_EINCOMPLETE result and have a static is_path_rooted function within
  mod_rewrite to test the complete and some incomplete path results.

  Don't have time to work up a patch at the moment, but thought I ought to
  add some observations while they are fresh in my mind.
Comment 3 spoon 2003-02-25 04:02:00 UTC
I to am having this EXACT problem. I thought maybe i just wasn't getting the 
grasp of Mod_Rewrite, but it turns out to be a bug!  :-(

Any update on this bug? Been a couple of months.
Comment 4 Rik Arpino 2003-02-25 13:03:41 UTC
After a bit of playing around, I found that version 1.3.26 did NOT suffer from 
the same problem - in fact I was hard pressed to find problems with mod_rewrite 
in the 1.3.26 packaged version on win32. Dunno if this helps anyone? Sorry for 
not updating sooner.....spoon reminded me!!!
Comment 5 André Malo 2003-02-25 13:19:23 UTC
Some patches were made to the main dev branch (2.1) and are proposed for backport.
I think, they will solve your problems and hopefully they will go into next 2.0
and 1.3 releases.

Thanks for your reports and thanks for using Apache!
Comment 6 spoon 2003-02-25 15:04:08 UTC
Wonder how long till the next release :-)  Is there a workaround in 2.x that 
was not mentioned? Possibly some way of tricking it? Or possibly access to 
Comment 7 André Malo 2003-04-04 22:54:41 UTC
Uh, sorry overlooked your questions ...

However, it should be fixed in 2.0.45. Please reopen this report if it's not.