[Looking for Charlie's main web site?]

Setting up ColdFusion to process html or other file extensions

As a follow-on to my last entry, Setting up CFBuilder to process htm files with the ColdFusion editor, I wanted to offer more info for those who may want to know more about this--or ensure that more is shared with any who would consider doing this.

If you're looking for how to configure CFBuilder to open htm files with the CFML editor, see that other entry. This one instead is about the related idea of having CF (the server) process htm (or other) file extensions. There are certainly pros and cons.

First, how to configure it in CF

Since I suspect some of the first people to come look at this will be those who want to do it, for any reason, the good news is that yes, you can do it, and it's been documented by many. I won't rehash the details, but instead will point you at any of several resources that do. It's not heard, though it does require a restart of CF (and perhaps your web server) to take effect.

Update for CF10: I wrote this entry in 2011, and since then CF10 has come out and things are indeed different. Michael Sprague has documented how to do it in CF10. (Thanks for sharing that as a comment, Michael!) We now need to edit the uriworkermap.properties file for any web connectors we have setup with CF. See the aforementioned blog post for details. Beyond those differences detailed there, some of the other info I share below may still be of interest to those on CF10 and beyond.

First, Adobe documented it long ago. It's a pretty old and barebones article. It makes only a passing reference to the need to also change the configuration in your web server. To be clear, you do need to make the needed changes to the web.xml file if using an external web server like IIS or Apache, but the point is that you also then therefore need to also make changes in that external web server.

Fortunately, a more modern Adobe technote does address that additional detail. And this solution works for CF 6, 7, 8, and 9. (With Zeus being built on Tomcat, it may well be quite different then.) Do be careful to look closely at the values, as some may change from release to release ("macromedia_mapping" vs "coldfusion_mapping").

Other writers also addressed the issue over the years. For instance, Steven Erat blogged more about it, as did Peter Bell, Brian Anderson of Hostek, Steve Cross, and Tony Weeg, to pick just a few.

2017 Update: A commenter pointed out that one of the links in this 2011 post no longer worked, and I see that I had a few such now-broken links. I have updated those not working as of 1/13/17 with links to the web archive version of the pages as captured at some time in the past. I'm sure I have other posts from years gone by that could benefit from such updates, but with almost 500 posts I probably will only correct those that people point out have issues. :-)

My point is, clearly many do find this an intriguing idea, for whatever reason. So why might one want to?

Why people might want to do this

There can be several reasons why people want to do this, some reasonable and some questionable.

I suspect that many delight in (or are compelled to explore) the idea of "hiding" their server implementation. By using htm files rather than cfm ones, no one need know they use CF (by the URLs of their page requests).

Of course, they could use still some other extension, whether some new one not used by anyone else, or perhaps one that others do know, and the solution above works for that as well.

For instance, I've known people who have configured things so that files with the php extension were handed to CF: not because they wanted CF to process PHP code, of course, but rather just because they did NOT use PHP and therefore just wanted to make it seem to the world that they did.

They may hope to throw hackers off the trail, or may want to avoid having to explain to folks that/why they use ColdFusion (sad that this should be the case, but some have felt the need).

Why people might not want to do this, and counters to such concerns

For all those who like the idea, there are probably more who spurn it, again for a number of reasons.

I'll say that while on the surface their concerns may seem clear-cut, as with so many things, "it depends". Those who might still want to try the alternative configuration for whatever reason might offer some reasonable counters to those concerns. Again, I'm not on either side in this debate. I'm just reporting observations for consideration. :-)

The concern of processing all HTM files as CFM, and the counters

For one thing, those who do not like the idea would point out that having htm files processed by CF runs the risk that now EVERY htm file will be processed by CF, even if it has no CFML in it at all, which of course would add overhead for the page execution time and would also add useless overhead to CF.

A counter some may propose is that one could set things up to use *.html extensions for "real" html pages and *.htm for "html/cfml hybrid pages, so that hopefully at least you only have CF process what you really think should have CFML.

Still others would note that they could also control whether and when they do this in the web server, so that perhaps it's only some website or some directories for which this configuration change (htm files being handed to CF) is made.

The concern that some things other than CF might be confused by the change

I noted above that some might use this approach simply to define not htm files but instead some other extension to be processed by CF. There's no real performance impact to doing that.

But it does raise the specter that some things may be confused by the change, if they expect to look for/find/use only cfm extensions. Possibilities include editors, log analysis tools, and so on. (I addressed how to change CFBuilder to open HTM files with the CFML editor in the last entry.)

Might there be other solutions, though?

Even with these concerns and their counters, some might want to propose still other solutions to achieve the goal of obfuscation (hiding the fact that you're running cfm files, if that's the main goal of the above). Let's take a look at a couple.

Using no extension at all

For one thing, some could just set things up so as not to use a file extension in their URLs at all, relying for isntance on the web server support of default documents (like index.cfm) to point to one file in the directory. No, it won't work for everyone, but I in fact do that frequently on my own site, such as for http://carehart.org/presentations/, http://carehart.org/articles/, or http://carehart.org/consulting/. I never bother with the index.cfm, as the web server figures it out for me.

Again, though, that approach only works when you can have one file per directory.

But someone has shown using a variation of the technique above (changing the extensions handled by CF) to have CF process requests for files that have extension at all. It's "out of the box" thinking, but I share it if it may interest someone.

Another solution: URL Rewriting

I'm sure some have been champing at the bit the whole time they've been reading this article, because they know something that perhaps others do not. Another solution for all this trickery above would be to use URL rewriting instead, so that you don't change the file extensions but instead you just don't use any at all in the URL.

With that approach, you configure things on your server (often via an extension to your web server) so that when people ask for one file, they're really sent to another. So if someone asks for url abc (whatever that is, in terms of domain, path, file, path_info), they are instead shown the result of processing file xyz (whatever that may be, to suit your interests), but the browser URL still shows the url as abc.

URL Rewriting can completely hide the underlying server implementation, or whatever level of it you choose, such as hiding what extensions you use, your use of query string/URL variables within code, your use of deep directory structures, and so much more.

This is not the place to discuss and debate all the pros/cons and even alternatives for URL rewriting, but I'll note that I do have a category for them with several alternatives (free and commercial, for Windows and Linux) at my CF411 site's category for URL Rewriting Tools .

BTW, the URLs for my cf411 site are themselves processed by a rewrite rule, though slightly different from what was just discussed. Note that that url I just shared, http://www.cf411.com/urlrewrite, ends up as http://carehart.org/cf411/#urlrewrite. You'll see that in the browser. Not only does the domain change (I wanted to people to get to it as cf411.com), but you also end up within a given subdirectory of my carehart.org site (the cf411 site is really just a subset of that main site).

And finally the URL ends up showing use of a page anchor (the #) to jump down in the very long page to the section chosen.

I wanted to be able to share URLs without all that noise. You've got to admit that cf411.com/urlrewrite is just smoother than carehart.org/cf411/#urlrewrite. :-)

Of course, I could have implemented the rewrite to keep that "new" url hidden. I just didn't bother. But if you're new to url rewriting, do remember that you CAN have the "resulting" url hidden from the user.

So, there you have it. A problem, some solutions, some concerns, some counters to those, and still other alternatives. I'm sure some are thinking "man, I never thought there could be so much to consider for this simple idea". But as always, there are just lots of things to consider, and as a troubleshooting consultant, it's my job to find, understand, and offer solutions to such problems.

But I could well have missed something significant. I know that some people may have far more experience with this particular problem (and to be honest, this is not one I help people solve often. It came up today for one user, so I researched and wrote here about it.)

But I do recognize that there is often more to a problem than seems to most at first, and I wanted to share the observations with any who may appreciate it. That's how I roll. Let me know what you think.

In case anyone is interested, the process for setting this up changed slightly for ColdFusion 10.

# Posted By Michael Sprague | 5/30/12 9:54 AM
Thanks for sharing that, Michael.
# Posted By Charlie Arehart | 5/30/12 10:06 AM
Two things:
1. One reason for processing HTM files as CFM files is if you are converting a website to CFM from HTM you may not want to change all of the links to the converted pages to have the new CFM extension.
2. Doesn't URL rewrite confuse and annoy search engines?
# Posted By Kenneth Gladden | 6/8/14 1:25 PM
Can someone share how to do this on CF10? The link to the CF10 is no longer working. Thanks in advance.
# Posted By Jack | 1/12/17 4:32 PM
Jack, thanks for pointing out the broken link. No need to ask if "someone" can help. I'm still here creating and managing the content. :-)

Indeed, I see that the post (from 2011) had a few such now-broken links. I have updated those not working as of today with links to the web archive (archive.org) version of the pages as captured at some time in the past.

That's something you should take note of, in case you ever come across any other such broken links. Some people just don't keep their sites going for years and so many old links do break , so the archive.org service is a wonderful one to take advantage of.

And I'm sure I have other posts here from years gone by which could benefit from such checks and updates, but with almost 500 posts I probably will only correct those that people point out have issues. :-) So again, thanks.
# Posted By Charlie Arehart | 1/13/17 1:32 AM
Is modifying the uriworkermap.properties the only thing in this process? Do you not modify the web.xml or isapi setting in IIS? This alone isn't working for me. I'm completely stumped moving from CF9 to 2016.
# Posted By Tony B | 1/24/17 5:34 AM
Tony B,

I am running in the same thing on 2016 and IIS 8.5
# Posted By Tim Cunningham | 1/31/17 4:02 PM
Tony B,

I found that I had to add to the C:\ColdFusion2016\cfusion\wwwroot\WEB-INF\web.xml a servlet mapping for my custom extenstion. I choose an unused id number (in my case 32 and 33) see example below.. Restarted CF and my *.do file that didn't work before worked.

<servlet-mapping id="coldfusion_mapping_32">
   <servlet-mapping id="coldfusion_mapping_33">
# Posted By Tim Cunningham | 1/31/17 4:15 PM
Hi, guys (Tim and Tony). Yes, you still need to do the web.xml changes in CF10 and above. That was indicated in the blog post from Michael Sprague that I pointed to (and whose link I updated when Jack complained it was no longer working.) Note that he had said in his post, "In CF10, there is now an *additional step* that is required due to TomCat" (emphasis mine).
# Posted By Charlie Arehart | 1/31/17 9:30 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005. (Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting