Problem with .htm files

I am using static htm files on server, but I need a "parameter"-like url

[welcome3]

There are some files on a server: "m=20081212.htm","page=12.htm", "p=673.htm" and some others.

I need them to be opened after requests like:

example.com/?m=20081212
example.com/?page=12
example.com/?p=673

I tried lots of variant but all the attemps were not successfull. The code listed below is not working too. :(

RewriteEngine on
RewriteCond %{QUERY_STRING} ^.*$
RewriteRule ^(.*)$ $1.htm [L]

Please help me.

[g1smd]

Is the 'equals' sign valid in a filename? I think not. It's certainly not standard, and I can think of several reasons why it would be a bad idea.

If the filename is index.htm and is defined in DirectoryIndex and .htm files are able to be parsed for PHP (or whatever it is that you use) scripts, then you don't need any sort of rewrite rules to make the URL example.com/?x=y connect to the file index.htm using parameters x=y with that file.

Where you would use a RewriteRule, is to make a URL like example.com/page/12 connect to an internal file at /index.php?page=12. That's the more normal usage of such a rewrite.

Is that what you want to do?

[welcome3]

There is no php code on a site just now. I want to keep the structure of a previously php-based site on a simle static htm files. There is no possibility to whrite a cms for this site and the main aim is to keep a structure as it was earlier.

Maybe I should use some %{QUERY_STRING} rule?

Now I've got a .htaccess file that allows to open pages like example.com/p=123

and it would be nice if I could open this file by typing

example.com/?p=123

in a browser.

[g1smd]

Do you want to keep using the old URLs that the site used to use, or do you want to migrate to new URLs?

[welcome3]

I want to migrate to new ones :)

p=123.htm should be opened after typing example.com/?p=123 in a browser.

[welcome3]

example.com/?m=20081212 -> m=20081212.htm
example.com/?page=12 -> page=12.htm
example.com/?p=673 -> p=673.htm

something like this.

[jdMorgan]

You need to back-reference the query string value then, not the requested URL-path:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^$ %1.htm [L]

This does not redirect the client, so the URLs will remain as they were before. It only changes the filepath that the server will use to serve requests for the old URLs.

Jim

[Caterham]

But you don't want to give s/o the control of the beginning of the substitution (esp. from the query_string which is completely unparsed); esp. if CVE-2006-3747 is not fixed on that server due to lazy updating.

[welcome3]

Jim, everything works perfectly. Thanks a lot!
Жыве Беларусь!

[jdMorgan]

I looked up that CVE again, but there wasn't any immediately-findable info on exactly what the reported exploit might look like. So if possible, make the query string pattern very specific, to avoid whatever weird character sequence it is that can be exploited on un-patched servers.

Something like this would be safer:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^([a-z]+=[a-z0-9.]+)$ [NC]
RewriteRule ^$ %1.htm [L]

Yet another reason to avoid using the ".*" pattern...

Jim

[Caterham]

You shouldn't find that clearly worded "how to expose". An attacker needs to control the start of the substitution, so the easiest way is to force an URL-path (by prefixing the backreference with a slash).

[jdMorgan]

Ahh, OK... I habitually do that in my own code, but it occasionally seems to cause trouble for others (maybe due to incorrect DocumentRoot definitions?).

So, further hardening the code, we end up with

RewriteEngine on
RewriteCond %{QUERY_STRING} ^([a-z]+=[a-z0-9.]+)$ [NC]
RewriteRule ^$ [b]/%1[/b].htm [L] 

Thanks,
Jim

[Caterham]

but it occasionally seems to cause trouble for others (maybe due to incorrect DocumentRoot definitions?)

It shouldn't because Apache needs an URL-path for an internal redirect (

ap_internal_redirect()

). Problems should be a problem of the redir processing. If your don't supply an URL-path directly in the substitution (nor an URL of course), mod_rewrite will build an URL-path either via replacing the per-dir prefix with the URL-path from the directive

RewriteBase

or by stripping the DocumentRoot. The later one fails when the request was not translated invoking the DocumentRoot (Alias, various ways of vhost mass hosting etc).

However, supplying an URL-path will stop mod_rewrite's loop detection-abort-function (because this is based on r->filename, the full physical path).