Maybe this help:
[webmasterworld.com...]

You don't have to change the names of the files!

You can set things so that any .html file is parsed as if it were a SHTML page, or you can internally rewrite the URLs so that the real name of the page isn't seen: the public continuing to see the old name forever.

Does this not create a potential duplicate content issue with Google? If the old page is html, and you have the server parse html pages as shtml, does that not create two identical pages with different URLs? (Or URIs, to be perfectly correct.)

http://example.com /page1.html
http://example.com /page1.shtml

Or does this cause the server to do a 301 redirect from html > shtml?

Apache servers can parse .html files without changing the file suffix to .shtml.

The .shtml suffix is just a clue to the server to parse the file for code before sending. By using a handler, you can tell the server to parse .html files in the same manner that it parses .shtml.

This causes no re-direct and is invisible to the public.

It parses the files as IF they were SHTML files but the file name is unchanged and still ends in .html as before.

OK, gotcha. I never understood that the server would do that. I figured there would be some sort of redirct. That's good to know, as I have several pages that I didn't want to change extensions on.

Concept works great. I told ASP to process all .htm files and now I can reconfigure them on the fly.

Be aware that if you make apache parse EVERYTHING as SSI it will dramatically hit processing resources.

There is a reason shtml has it's own extention. If it was SSI standard for all pages, the server would attempt to parse and process ALL your pages looking for includes.

So if you have a very popular site, and you server tons of pages, making apache parse html exactly link shtml you will see a preformance hit on the server. Just an fyi...

Thanks for the help guys

I too have thought about doing this, with the template/menus of the site, but the server impact is my unknown concern. I'm not sure how much it will impact the server and site and am not sure I want test it. I probably should as that's the only way of knowing. Any guideline or benchmarks on how much of an impact having all pages parsed as shtml?

As far as server impact is concerned, there may be a way to test the change incrementally.

Again, if your running apache, you can add the line:

XBitHack on

to any .htaccess file. By then changing the permission of any .html to 744, instead of 644 causes the .html file to be parsed.

This could be done incrementally to test the impact on your server.

Apache site has more info [httpd.apache.org] on this.

Check out the differences between a redirect and a rewrite.

One method issues a 301 or 302 code back to the original request. The other is silent and invisible in operation.

You can redirect A to B while having a rewrite from B to A. So, in this case, B is indexed, and the "real" name on the server is A, but A can never be indexed.

g1smd,

They'll get confused with all of the options and the ones that are out on the table aren't all of them ;-).

They could always have a master build system setup one way, then walk the site with all of the ssi in it building an exposed site without ssi under the current names. Yes a bit involved and no longer truely dynamic but not out of the question, it all depends.

Plenty of ways to do things, frequently more than one might originally think exist.