(This is a reprisal and update of an old blog entry I'd done back in 2003, on a blog site that will soon no longer exist. I'll be reprising a few such blog entries in coming days/weeks, to keep them around for posterity [and to save some having to dig for them in the archive.org site] since often the info offered then may be just as valuable now. I hope that in time these new versions would come up if people do searches that would have found the old entry.)

So, about these http headers, while CFML exposes them in a dump of the CGI scope, such as the user-agent field which shows up as cgi.http_user_agent, the issue is that you would not use that name, nor even "user_agent", when specifying it in a CFHTTPPARAM. The proper way to pass the user agent in a CFHTTPPARAM would be as follows:

Why is this an issue, and how may it happen?

An easy mistake to be lulled into

The point is that the name of the header you specify must be a name that is correct according to the http specifications, not the headername as it appears in CFML when you dump the CGI scope. The problem is that CF tries to "help" you by how it labels the headers in these scopes, but it does not show them in the actual name you must specify if you're going to be sending it in a CFHTTPPARAM request.

It's is an easy mistake to be lulled into, especially if you aren't careful to confirm the results in the page you are calling. And if you are trying to call some non-CF server, and things aren't working, this may well be the reason.

Other possible headers of interest

Other headers of possible interest that you may want to specify when doing a CFHTTP request are Accept, Accept-Encoding, Referer, and so on. So if you were wanting to send/spoof what CF would show as the cgi.http_referer variable, you'd want to send it with the name just as "referer".

Alternative type="cgi" and type="header"

FWIW, note that I am using here the type="CGI" value. CFML also supports a type="header". The difference is in whether CF urlencodes the result before sending it (it does not for type="header"), which could be another issue to consider. This encoding can also be turned on or off with the available "encoded" attribute, at least for type="cgi".

Yes, you don't need to use cfhttpparam for sending the user agent

Finally, someone may want to point out that you don't even need to use CFHTTPPARAM to send the user agent, since CFHTTP offers a separate built-in USERAGENT attribute which can be used instead. Yes, this is do.

I suspect it's an older approach that either existed before CFHTTPPARAM permitted passing it, or it was put in as a shortcut.

But the point of this entry is that if you do need to set this or any other headers within the CFHTTPPARAM, be aware of using the correct http header name.

I will propose that they should be done from oldest to newest. Here's why.

If you look at the list of CF security hotfixes offered here, you may wonder whether to start with the most recent ones, or the oldest ones. If you look at their respective technotes and zip files closely, you may find that some are truly independent of the others. But it's also a reality that some do supercede the others. That may be obvious to some, but I wanted to offer a case in point.

Consider the hotfixes for APSB11-14 and APSB11-04. If you look at the zips for these, you may notice that they offer a few files (in the web-inf/lib directory) that appear identical in name (log4j.properties, esapi.properties, validation.properties, commons-fileupload-1.2.jar, and so on.) If you had applied the later one first, you may then wonder if it's significant if you then want to apply the older one.

Well, those files are in fact identical (I did a compare). But the files in the CFIDE associated with each hotfix are in fact quite different and so the later ones would supercede the earlier ones.

So you would NOT want to do them in the wrong order (older before newer). It's just not always clear from the technotes whether this is an issue to worry about, so I wanted to share it here.

This is not the place for discussion of how complicated CF hotfixes are. That's been discussed to death in many places. If you didn't know, Adobe is indeed addressing the problem in the next release, currently code-named Zeus. You can read about this and 50 other currently publcized Zeus features in a talk I did. And note that they have said they will be back-porting some of that to earlier releases.

Hope it's helpful to someone. If you may have a different experience or opinion about the order of applying security hotfixes, feel free to share it.

PS I have written previously about easy mistakes you can make in applying any CF hotfixes, and how to avoid them. See CF911: Are you finding CF (or CF Admin) busted after applying a hotfix? Three possible reasons. I have also written about the challenges of trying to "skip" cumulative hotfixes. You may want to read them if you've not yet done so.

But again, please hold off on any comments about the complications of CF hotfixes. There's nothing more to do than deal with the situation as it is and await Adobe offering a better solution.