Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

A Cure for Arachnophobia

A Cure for Arachnophobia

Barely a week goes by without someone asking me about ColdFusion and search engine-friendly URLs. This is one of those topics that ColdFusion developers have been discussing for a long time - I first started a thread on this subject on the Allaire Developer's Forum close to five years ago. As this topic keeps coming up (and because three of you e-mailed me to ask about it this morning), I decided to scrap the column I was writing in favor of an explanation of all this once and for all.

Search Engines and ColdFusion
Here's the problem. Many search engines index sites by spidering them - starting at a known point, indexing that retrieved page, parsing it for embedded URLs, and then retrieving and indexing them too. They keep doing this until they have retrieved and indexed all linked pages in a site.

At least that's how it's supposed to work. Where things get complicated is when dynamic pages are indexed, or rather, when they're not. Some spiders won't index URLs that are dynamic, the theory being that since the content changes all the time there's no point in indexing it - after all, it may not even be the same content on subsequent accesses. So this link would be followed and indexed:

<A HREF="catalog.cfm">Catalog</A>

but this one may not:

<A HREF="catalog.cfm?dept=10">Catalog</A>

You can see the problem: ColdFusion developers (as well as ASP, PHP, Perl, Python, and JSP developers, among others) build dynamic pages. That's why we use ColdFusion - if all content was static we'd use plain old HTML without any server-side processing at all. We use ColdFusion because we want and need dynamic content - content that spiders may choose to ignore. If search engine indexing is a requirement for you, that can pose a real problem.

The Basic Solution
The solution to this problem is actually quite simple. What is it that tips off the spider, telling it that the page is dynamic? It's the query string portion of the URL, starting with the question mark. That question mark separates the URL (the file to be retrieved or the script to be executed) from any passed parameters (usually in name=value pairs).

The solution is to simply not have a query string - no question mark, no values passed after it, and no name=value pairs. Simple, eh? Yep, until you actually need passed parameters. Then what?

Well, look at this URL:

http://host/path/catalog.cfm/10

What happens when this is processed? catalog.cfm is the file to be executed and anything after the file name is ignored altogether. Even though the Web server and ColdFusion ignore it, that doesn't mean you have to. Using CGI variables (like PATH_INFO) you can access the complete URL - even parts of it that may be ignored by other processes or applications. The following snippet will display the complete path (minus any host and protocol information, although that's available in another CGI variable if needed).

<CFOUTPUT>#CGI.PATH_INFO#</CFOUTPUT>

Using the above URL this will display:

/path/catalog.cfm/10

We now know how to get the passed information. Next you need to remove the path and script name. You could do this by searching for the CFM file, but there's an easier way using yet another CGI variable, this time SCRIPT_NAME, which contains the name of the script being executed (here /path/catalog.cfm):

<CFSET query_string_length=Len(CGI.PATH_INFO)-Len(CGI.SCRIPT_NAME)>
<CFSET query_string=Right(CGI.PATH_INFO, query_string_length)>

The first <CFSET> gets the length of PATH_INFO and subtracts the length of SCRIPT_NAME from it, giving us the length of the section at the end (the data we want). The second <CFSET> uses Right() to extract the desired data, saving it in a variable named query_string. Displaying query_string would result in this output:

/10

That's how you get the data off the end of the URL.

Note: Depending on the Web server and OS being used you may find different CGI variables or different values in them. You can use <CFDUMP VAR="#CGI#"> to see all the CGI variables available to you (and you'll be able to adapt the code here accordingly).

Making It All Work
Now that the basic concept is clear, let's take this one step further. How can you pass multiple parameters? Well, you could pass three parameters, each separated by a /:

http://host/path/catalog.cfm/10/0/B12

But you would have no way of knowing which was which, what their names should be, and they'd always have to be in order (something you typically don't worry about when working with URL parameters).

While the technique is sound, the implementation can be improved by simulating name=value pairs. Look at this example:

http://host/path/catalog.cfm/dept/10/user/0/item/B12

There are now six values passed to the URL; each set of two is a name and value pair. Here it's dept=10, user=0, and item=B12. The advantage of this enhancement is that the variable name is known, the order of pairs is irrelevant, and the URL is easy to construct.

All that is required now is a simple way to extract these values and turn them into real URL values (after all, your application code shouldn't have to worry about manipulating this data; as far as it's concerned these are URL parameters plain and simple). This is where ColdFusion's list functions come in handy:

<!--- Extract "query_string" from full path --->
<CFSET query_string_length=Len(CGI.PATH_INFO)-Len(CGI.SCRIPT_NAME)>
<CFSET query_string=Right(CGI.PATH_
INFO, query_string_length)>

<!--- How many items in "query_string? --->
<CFSET items=ListLen(query_string, "/")>

<!--- Loop through list, pair of items at a time --->
<CFLOOP FROM="1" TO="#items#" STEP="2" INDEX="i">
<!--- Save this URL parameter --->
<CFPARAM NAME="URL.#ListGetAt(query_string, i, "/")#"
DEFAULT="#ListGetAt(query_string, i+1, "/")#">

</CFLOOP>

The first two <CFSET> statements simply extract the virtual query_string (as we saw earlier). Next we need to know how many items query_string contains. All ColdFusion list functions take an optional delimiter as a parameter, and so ListLen(query_string, "/") returns the number of items delimited by / (in this case, six).

Next, a <CFLOOP> is used to loop through the items, from one to however many there are, stepping two at a time (because every two is a set). Within the loop <CFPARAM> is used to create the variables. The value passed to NAME is the first of the pair (i) and the value passed to DEFAULT is the second (i+1). For the first set of values (/dept/10) the <CFPARAM> would be:

<CFPARAM NAME="URL.dept" DEFAULT="10">

There you have it. By the time the </CFLOOP> is reached, a set of URL parameters would have been created. This code could be placed once at the top of a page, and all other code could refer to URL parameters without knowing they were actually faked. In addition, as <CFPARAM> was used (instead of <CFSET>), you wouldn't overwrite variables if URL parameters actually did exist.

Clean, safe, and spider friendly, too.

Custom Tags to the Rescue
Of course, you wouldn't want all that code in every page - this type of processing is ideally suited for custom tags - thus my <CF_FakeURL> tag. Listing 1 shows the complete code.

Let's take a quick look at the tag. It starts with comments and a description, as all code should. Then a <CFPARAM> is used to define the default delimiter (a slash). Next the virtual query string is extracted using two <CFSET> tags (as we did earlier).

For this code to work there must always be an even number of elements (there are two for every parameter, one for name and one for value). The next <CFIF> statement uses the MOD operator to make sure the number of items in the list is a multiple of two - if this is not the case the list is not processed.

Within the <CFLOOP> the two values (current and next) are extracted, and then <CFPARAM> creates the URL variable.

Now all you need to do is call <CF_FakeURL> in your page and any faked URL parameters will be available for you to use. When you create your URLs just change this:

file.cfm?LName=Ben&FName=Forta

to this:

file.cfm/LName/Ben/FName/Forta

Simple as that.

Summary
Arachnophobia is the irrational fear of spiders - a fear that many ColdFusion developers seem to be suffering from. As you can see, with a little ingenuity and some good old CFML, there's a very workable solution to help you overcome this fear. Enjoy!

More Stories By Ben Forta

Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Daniel Leroux 12/16/03 02:09:53 PM EST
Vikas Tailor 07/26/03 04:18:00 PM EDT

Hey all,

I used this great strategy and all of a sudden it stopped working! Could it be possible that the web server administrator no longer allows this? For example, go to http://www.linkexchanged.com/directory.cfm/Arts

This use to work, but no longer does.

Thoughts?

Laura Schneiderman 04/23/03 11:01:00 AM EDT

We've noticed that Norton firewall scrambles CGI variables. This CF_FakeURL tag relies on CGI variables. Has anyone else mentioned this problem?

Stephen Cassady 07/08/02 11:39:00 AM EDT

MX has many undocumented changes for 5.0 to MX.

One includes the new wal URLs are examined. I have a similiar script I picked up from the developers excange which allowed me to do http://www.site.com/page.cfm/var1.value1/var2.value2/var3.value3

And it also doesn't work now. Massive blow to the way everyting works, and, ironically, to the now indexed - but non-functional pages in all the search engines.

Arrgh. And there are other undocumented changes too (part of the CFIDE directory beeing in the site map - something we removed for security issues - for auto JavaScript from things like CFFrom, and a CFFILE problem).

Stephen Cassady
[email protected]
http://www.lopedia.com

Seth Aaronsen 06/30/02 06:30:00 PM EDT

We have successfully used CF_FakeURL on CF 5.0

We are having problems getting CF_FakeURL to work with CFMX standalone. This has been documented in the latest allaire message boards with the similar tag from Fusebox -- CF_FormUrl2AttributesSearch. CFMX will not process the strings http://www.mysite.com/page.cfm/variableid/value -- Please try this and you'll see.

We have tried to tweak the settings in the C:\CFusionMX\wwwroot\WEB-INF\web.xml doc by adding,

CfmServlet
*

but this does not work for us.

Do you have some suggestions?

Jill Crawford 02/22/02 09:51:00 AM EST

Thank you for the continued information that proves to be invaluable.

I have created URLs like http://www.yoursite.com/index.cfm/productID=item similiar to what you have suggested but and have lost the query string (everything after .cfm) in the log files for IIS since doing.

Apparently ColdFusion no longer believes these are URL parameters and does not return them to IIS to write as the cs-uri-query. Is there some way to capture the paramaters to the log file?

I would greatly appreciate any assistance you can give or point me towards.