Trimming characters through mod rewrite

This is a question related to using mod_rewrite to create static URLs

[jepler]

Hello,

This is my first post in this forum.

I successfully (sort of) used mod_rewrite in my .htaccess file to transform what was once a dynamic URL into a static URL. What was once this:

http://www.example.com/picture.php?image=foobar.JPG

can now be accessed by typing the following in the browser address:

http://www.example.com/picture-image-foobar.JPG.html

This is what I have in my .htaccess file:

Options +FollowSymLinks
RewriteEngine on
RewriteRule picture-image-(.*)\.html$ picture.php?image=$1

My question is, "is it possible to rewrite the directive to drop the four characters representing the extension (e.g. .JPG) from the static URL?" If so, how?

Can someone confirm for me that search engines will now index my pages using the static URL address instead of the dynamic address? I'm thinking I may still need to do something to get this to work.

Thanks,

-Jim

San Diego, CA

[edited by: jdMorgan at 3:35 am (utc) on July 30, 2007]
[edit reason] No URLs, please. See Terms of Service. [/edit]

[jdMorgan]

Well, yes and no.

First, mod_rewrite does not determine the URL -- be it static or dynamic. What you publish as a link or an <img src="..."> tag on your pages is what determines the URL.

Now, if you want to eliminate the *need* to include the ".JPG.html" in those links, then edit your pages (or your database, whichever applies) to change those on-page links, and then modify the rule:

Options +FollowSymLinks
RewriteEngine on
RewriteRule picture-image-(.+)$ picture.php?image=$1.JPG [L]

Note that this makes your linked image URLs entirely extensionless. You can, of course, add the .html back on, but I don't see why you'd want to.

Jim

[jepler]

thanks for the reply. I plan to change the link code on the referring page to point to the "static" URL instead of the dynamic link, but I was wondering if there is something else I need to do? It seem like many of the sources I've reviewed state that you need to use the mod_rewrite TWICE, to change it on both the incoming and outgoing ends. This has caused me some confusion.

Regarding the dropping of the .JPG, I guess I can do that through an explosion of some sort using PHP on the referring page. I was just wondering if there was an easier way to do it using mod_rewrite before I go that route.

-Jim

[jdMorgan]

This thread, Changing Dynamic URLs to Static URLs [webmasterworld.com], from the Apache section of our library, describes the three steps required to implement the whole process.

Jim

[g1smd]

The rewrite process translates a requested URL into a file name in the server. You can do just about any change that you can think of in this translation.

[jepler]

jeMorgan wrote >>>> This thread, Changing Dynamic URLs to Static URLs, from the Apache section of our library, describes the three steps required to implement the whole process. <<<<<

yes, in fact I read that article before posting here. The part that I was unable to get to work was related to the third bullet, "Add additional mod_rewrite code to detect direct client requests for dynamic URLs and externally redirect those requests to the equivalent new static URLs." In my case I didn't pass as many variables as shown in the example. I only had one variable and my code looked something like this:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /details\.php\?product=([^&]+)\ HTTP/
RewriteRule ^details\.php$ http://example.com/product/%1? [R=301,L]

I used a cool tool I found on seo chat to generate the code that I'm using in my .htaccess file. It did a great job of internally rewriting a static URL to a dynamic query, but did not provide the ability to detect a client request and externally generate the proper directive.

***EDITED***
After giving this some more thought, I think I understand why I'm having problems. I'm trying to not only translate a dynamic URL into a static URL, but I'm also introducing a new variable into the equation. In order to address the external rewrite issue, I'll probably need to create some type of intermediate action to switch the new variable into the URL and then use mod_rewrite to rewrite the static portion. I think I'm good to go. Thanks for your help.

-Jim

[jdMorgan]

Your code looked OK, although if you've only got one name/value pair, I'd suggest one small change to improve its efficiency:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /details\.php\?product=([b][^\ ][/b]+)\ HTTP/
RewriteRule ^details\.php$ http://example.com/product/%1? [R=301,L]

Rather than looking for a second ampersand to end the pattern-match, this looks for the space preceding "HTTP", and is therefore faster (since there will never be a second ampersand, so we want to avoid several unnecessary back-off-and-retry cycles).

Try to get away from "automatic code generators". Once you've gotten proficient with mod_rewrite and regex, you'll come to appreciate how, in the attempt to simplify code generation, they often produce awfully-inefficient code, and how some results have logical and/or lexical holes you could drive a dump-truck through...

These latter are latent defects, lurking around to give you problems with URL-paths that unexpectedly match their patterns. If you are lucky, the result is glaringly obvious -- something breaks badly enough to get your immediate attention. If you're unlucky, you may only discover the problem weeks later due to a serious search ranking problem.

They also tend to generate patterns with multiple (.*) subpatterns in them -- an easy but horribly-inefficient technique that, used often on a busy site, will lead to a noticeable slow-down in the server. I've saved a few sites from forced server hardware or hosting-account upgrades simply by re-coding their auto-gen'ed RewriteRule patterns to be much more specific.

My earnest recommendation is that Webmasters should never use code that they do not fully understand; Otherwise, it's playing with fire. We do no-one any favors here by simply handling them code and saying, "Here, use this."

Jim

[jepler]

**[Removed by poster due to inaccuracy of statement]**