| Summary: | DocumentRoot not being appended to URL | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Rik Arpino <rik.arpino> |
| Component: | mod_rewrite | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | CC: | jessenig, slipszi, spoon |
| Priority: | P3 | ||
| Version: | 2.0.40 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
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).
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. 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. 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!!! 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! 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 apache-dev? Uh, sorry overlooked your questions ... However, it should be fixed in 2.0.45. Please reopen this report if it's not. Thanks. |
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 Rik