It seems, that mod_rewrite use all lowercase URLs under Windows. The typed URL was: http://www.site.com/Computers/Printers/page=2/order=d/sort=1 I used the following Rewrite rules in .htaccess: RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.site\.com$ RewriteRule ^(.*)/cat/(.*)page([0-9]+)[/]?(.*)$ /script.cgi?cat=$1&page=$3 RewriteRule ^(.*)/order(a|d)[/]?(.*)$ /script.cgi?%{QUERY_STRING}&order=$2 RewriteRule ^(.*)/sort([0-9]+)[/]?(.*)$ /script.cgi?%{QUERY_STRING}&sort=$2 RewriteRule ^/script.cgi(.*)$ /cgi-bin/script.cgi?%{QUERY_STRING} [L] But in rewrite_log.txt appears: (2) [per-dir c:/path/] rewrite computers/printers/page=2/order=d/sort=1 -> /script.cgi?cat=computers/printers&page=2&order=d&sort=1 I searched bugzilla, docs, faqs, asked IRC channels, but I did not find any issues about this problem/behaviour. I have disabled mod_spelling module, so that can not cause the lowercase URL issue in rewrite engine. I don't know other feature, what is URL case related, and is enabled or used in my server config. It may happen that mod_rewrite is treating URLs are all lowercase because of Windows FAT32 file system. Scripts should always get the correct case URL input, because if not, some specific scripts will fail. Best regards, Webmaster33
mod_rewrite doesn't modify the case without advice (aka RewriteMap). My first guess is, that this is a browser/proxy problem. Did you try another one or telnetting to the server?
BTW: there is a mistake in the example, however that does not affect the problem: The typed URL should be for the current rewrite rule: http://www.site.com/Computers/Printers/page2/orderd/sort1 And in rewrite_log.txt appears: (2) [per-dir c:/path/] rewrite computers/printers/page2/orderd/sort1 -> /script.cgi?cat=computers/printers&page=2&order=d&sort=1 >My first guess is, that this is a browser/proxy problem. It can not be a browser problem. I tried with both Mozilla and IE. Also tried the telnetting now. The response is: HTTP/1.1 200 OK Date: Mon, 29 Sep 2003 12:54:22 GMT Server: Apache/1.3.27 (Win32) Connection: close Content-Type: text/html; charset=iso-8859-2 But the "Computers/Printers" category parameter, appears to get passed as all lowercase to the cgi script, as: "computers/printers" I have only these modules loaded: LoadModule rewrite_module modules/mod_rewrite.so # module order ClearModuleList AddModule mod_env.c AddModule mod_log_config.c AddModule mod_mime.c AddModule mod_negotiation.c AddModule mod_include.c AddModule mod_autoindex.c AddModule mod_dir.c AddModule mod_isapi.c AddModule mod_cgi.c AddModule mod_asis.c AddModule mod_imap.c AddModule mod_actions.c AddModule mod_userdir.c AddModule mod_alias.c AddModule mod_rewrite.c AddModule mod_access.c AddModule mod_auth.c AddModule mod_so.c AddModule mod_setenvif.c Should I try another Apache version? I can not imagine what causes that mod_rewrite uses lowercase URLs. The [NC] flag is not used. The only possibility would be, that mod_rewrite converts URLs to lowercase under Windows/FAT32. And that would be a bug. Any idea?
Now I'm sure it's not a config problem. The problem also appears on Apache v1.3.28. I would try to make clear the problem. Test URL: http://www.site.com/Computers/Printers/Cables/index.html Using following rewrite rule I would like to use some part of the URL as input into a script: RewriteEngine on RewriteRule ^(/.*)/index.html$ /script.cgi?cat=$1 The problem is, that $1 will be not "Computers/Printers/Cables", but "computers/Printers/Cables". The script input needs the category name in correct case, doesn't matter if we use Unix or Windows. But in rewrite_log.txt appears: (3) [per-dir z:/dir/] add path-info postfix: z:/dir/computers -> z:/dir/computers/Printers/Cables/index.html (3) [per-dir z:/dir/] strip per-dir prefix: z:/dir/computers/Printers/Cables/index.html -> computers/Printers/Cables/index.html (3) [per-dir z:/dir/] applying pattern '^(.*)/index.html$' to uri 'computers/Printers/Cables/index.html' (2) [per-dir z:/dir/] rewrite computers/Printers/Cables/index.html -> /script.cgi?&cat=computers/Printers/Cables (3) split uri=/script.cgi?&cat=computers/Printers/Cables -> uri=/script.cgi, args=&cat=computers/Printers/Cables (1) [per-dir z:/dir/] internal redirect with /script.cgi [INTERNAL REDIRECT] (3) [per-dir z:/dir/] strip per-dir prefix: z:/dir/script.cgi -> script.cgi (3) [per-dir z:/dir/] applying pattern '^(.*)/index.html$' to uri 'script.cgi' (1) [per-dir z:/dir/] pass through z:/dir/script.cgi Is that normal? "computers/Printers/Cables" is inserted with $1, and not the expected "Computers/Printers/Cables". I know, it may be related to the Windows's case insensitive filesystem, however the rewrite feature is wrong that way. Script inputs are case sensitive on all systems, so mod_rewrite should be also case sensitive. Windows understands both lowercase and uppercase paths, so paths with correct case from mod_rewrite are treated well at system level. I think the bug is at "add path-info postfix" action, since the base dir is not "z:/dir" as would expected, but "z:/dir/computers". Best regards, Webmaster33 (using Apache v1.3.28)
It must be somewhere else. The path-info adding is correct, if z:/dir exists. Can you attach your whole configuration? Or better can you break down the problem to a minimal configuration? If you don't want to publish your httpd.conf you mail it me privately as well. Thanks.
Better sending privately. Thanks!
Received, thanks. I'm digging into it tomorrow (it's quite late here :)
This is resolved in Apache 2.0 - Apache 1.3 simply lowercased the filenames to 'canonicalize' them to their "one true name". Yes this was very hackish, but that's the Apache 1.3 on Windows solution - an interesting and clever hack. Apache 2.0 was written from the ground up - and this was taken into account. The file's *true names* are used in Apache 2.0 (as stored on disk as their long file names.) Also the "one true name", this takes a few more cpu/disk cycles but is more reliable and doesn't cause the sorts of problems you are encountering. Please upgrade to 2.0 to resolve your issue.
Yes, I upgraded to 2.0, and it works fine now. Thanks! >Apache 1.3 simply lowercased the filenames >to 'canonicalize' them to their "one true name" However I think, that this should be still fixed in v1.3.x. Unfortunately not the filename (or not just) was lowercased, but the path itself in the "add path-info postfix" phase. I think the base path is detected incorrectly: "z:/dir/computers" instead "z:/dir". The "/computers" string should belong to post part. Opinion? BTW: Why does it need to lowercase anything, when the FAT16-32 is case insensitive? If the URL part of the path is kept with original case, the Windows will still accept it.
Was this bug really fixed in v1.3.x?
Nope. (a) it's not a bug in mod_rewrite (b) it's fixed 2.0. As said, 1.3 will stay as is. Perhaps it should have better been resolved to wontfix...
>(a) it's not a bug in mod_rewrite If not a bug in mod_rewrite, then bug in Apache. Doesn't change the fact, that v1.3.x is not working correctly. >(b) it's fixed 2.0. As said, 1.3 will stay as is. I'm glad, that it's fixed in 2.0, but it still should be fixed in 1.3.x. I found a fix in 1.3.13, which seems interesting: " *) Add case_preserved_filename field to the request_rec structure. On systems with case insensitive file systems (Windows, OS/2, etc.), r->filename is case canonicalized (folded to either lower or upper case, depending on the specific system) to accomodate file access checking. case_preserved_filename is the same as r->filename except case is preserved. There is at least one instance where Apache needs access to the case preserved filename: Java class files published with WebDAV need to preserve filename case to make the Java compiler happy. [Bill Stoddard]" Isn't it something that may help current issue? Anyway, until it's not fixed in 1.3.x, I'm reopening the bug. Sorry.
Patches welcome ;-)
Whoops. Ok, this has simply got to be marked won'tfix. As I said 15 months ago - it is simply NOT possible to straighten this out in Apache 1.3/Win32. Nothing has changed, or will change, in that answer. If you don't like the behavior (certainly I don't :-) then upgrade to 2.0.
*** Bug 47393 has been marked as a duplicate of this bug. ***