Skip to main content
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Oguz Demirkapi
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Oguz Demirkapi ( @demirkapi )

Getting Header Values From A ColdFusion Request

Published in Comments (11)

Last week, Ray Camden commented on my post about sending multiple data parts in a CFHttp post. In his comment, he demonstrated how he posted custom header data to a Google API. While it was clear that I misunderstood the original question, seeing Ray's comment got me thinking; in ColdFusion I have only ever set Header values for a response or a CFHttp post - I have never gotten them from the current ColdFusion request.

The hard thing about testing this is that I sort of need two different pages - one that sets custom Header values and then one that reads them. I suppose I could have just used one page and read the Header values that came from the browser; but, I wanted to be able to see custom values that I set (which is more satisfying). First, I created a page that posted a CFHttp FORM and then CFDump'd out the response:

<!--- Build the calling URL. --->
<cfset strURL = (
	"http://" &
	CGI.serer_name &
	GetDirectoryFromPath( CGI.script_name ) &
	) />

<!--- Make a post. --->

	<!--- Send header value. --->

	<!--- Send form data. --->


		file="#ExpandPath( './data.txt' )#"


<!--- Output response content. --->

As you can see, we are simply posting some form data and a custom Header value: "Sarah=Stubby".

Once I had this page in place, I started to experiment with response.cfm to see how I could access the Header data. As it turns out, my first test was the only one I needed:

<!--- Dump out the request data. --->
	label="GetHttpResponseData() Values"

When we run the above code, we get the following output:

GetHttpRequestData() Can Be Used To Read Headers Values In A ColdFusion Request.

As you can see from the above CFDump, the posted Header values are readily available in the ColdFusion struct:


Wow, that was easy!

Want to use code from this post? Check out the license.

Reader Comments



I love CFFile - trying to upload without it would be cruel and unusual (like it is in ASP). The "content" is not just the file. The binary data should contain the file and the form field that we are submitting. However, as you can see form the CFDump, the binary data is empty. To be honest, I am not sure where the binary data goes. I don't know if this is part of ColdFusion 8's new file handling or if the form post data is stored elsewhere. I will look into this.


Hi Ben,

there's a typo in the third line of your example code (cgi.serer_name - should be server I assume).

On a different note, how can I per request set a HTTP-header for U-AX-Compatability (IE8 weirdness)? Instead of this <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> I want to do this
<?php header('X-UA-Compatible: IE=EmulateIE7'); ?>.

Can I just do this: <cfheader charset="UTF-8" name="X-UA-Compatible" value="IE=EmulateIE7"> and place this in my Application.cfm/cfc?



Huh, good catch on the typo. I have no idea how that demo would have run (I pretty much copy/paste my actual code). I must have accidentally deleted the character. You are right - should be "server".

As far as the IE compatibility, I am not sure that that is something you can try to override with the site headers. Maybe it is - I know extremely little about it (I haven't even downloaded IE8 yet.. shame shame).

I'll have to do some research before I can answer that.


Hi Ben,

I've done the research for you ;-) C here:

My question actually boils down to the cfheader issue!

Thanx up front.


Great post, once again, Ben. I was doing some CORS work and Google led me to this post to dig up the right combo for figuring out the referring origin, ie. GetHttpRequestData().Headers.origin. I then check that against an approved list of origins, and if it matches, return that back so the other site can post to the form. Seems to work nicely, and keeps security tighter than just going with the *.


Ack! Here's another side effect of this. Some of these variables are available as non-scoped variables (or at least I could not find them in any of the scopes named in the CF documentation).

In one script, we have (now "had"!) code that uses "origin" as an unscoped variable. It was defined in FORM scope (cfinput type="hidden" name="origin") in the submitting page. When the code referenced #origin#, instead of the form value it was getting "http://--domain--". This *ONLY* happened in Chrome, so was quite confusing / aggravating.

I found that by dumping out all of the values in getHttpRequestData().headers and replacing "-" with "_" in the name, I could see all of the header values. So, #origin#, #Content_Type#, #Content_Length# (notice the underscores), etc., are all defined -- I just don't know what scope they are in.

Unfortunately, whatever scope these are in takes precedence over the FORM scope, so our code was seeing "http://..." as the value for #origin# instead of the FORM.origin value. By replacing the unscoped code with scoped references, it is all working again in Chrome.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel