Tags like CFHTMLHead, CFAjaxProxy, and CFAjaxImport don't output their content into the regular ColdFusion output buffer. Instead they put their contents into a special header buffer which is dumped into the beginning of the output right before the request is sent back to the client. But what if you want control over where their output goes? CFSaveContent doesn't work on these bad boys. And even worse, <cfcontent reset="yes"> doesn't get rid of their output. The other day I got bit when trying to return the HTML of a rendered view via a proxy in ColdBox as a JSON string. The JavaScript output of the CFAjaxProxy tag was being appended to the beginning of the response and causing the result to not be valid JSON.Looking around on the Internet turned up a function credited to Elliott Sprehn to erase any content in ColdFusion's header buffer. Looking a little further, I found this method by David Boyer to actually retrieve the header buffer. I modified the latter to work with ColdFusion 8 and 9. Without further ado:
[code]<cffunction name="clearHeaderBuffer" output="false" returntype="void">
	<cfscript>
		var local = StructNew();
		local.out = getPageContext().getOut();
		while (getMetaData(local.out).getName() Is 'coldfusion.runtime.NeoBodyContent') 
			{ local.out = local.out.getEnclosingWriter(); }
		local.method = local.out.getClass().getDeclaredMethod('initHeaderBuffer', ArrayNew(1));
		local.method.setAccessible(true);
		local.method.invoke(local.out, ArrayNew(1));
	</cfscript>
</cffunction>[/code]
[code]<cffunction name="getHeaderBuffer" output="false" returntype="any">
	<cfscript>
		var local = StructNew();
		local.out = getPageContext().getOut();
		while (getMetaData(local.out).getName() Is 'coldfusion.runtime.NeoBodyContent') 
			{ local.out = local.out.getEnclosingWriter(); }
		
		if(listFirst(server.coldfusion.productVersion) LTE 7)
			{                                      
				local.field = local.out.getClass().getDeclaredField("headerBuffer");
				local.field.setAccessible(true);
				local.buffer = local.field.get(local.out);
				return
				iif(StructKeyExists(local,'buffer'),"local.buffer.toString()",de(""));
			}
		else // CF8 intruduced new header Buffer
			{
				local.field =
				local.out.getClass().getDeclaredField("prependHeaderBuffer");
				local.field.setAccessible(true);
				local.buffer = local.field.get(local.out);
				local.output =
				iif(StructKeyExists(local,'buffer'),"local.buffer.toString()",de(""));
				
				local.field =
				local.out.getClass().getDeclaredField("appendHeaderBuffer");
				local.field.setAccessible(true);
				local.buffer = local.field.get(local.out);
				
				return local.output &
				iif(StructKeyExists(local,'buffer'),"local.buffer.toString()",de(""));
			}                              
	</cfscript>
</cffunction>[/code]
Usage looks like this:
[code]Hello World
<cfajaxproxy cfc="proxy.pxMyProxy" jsclassname="pxMyProxy" />
<cfhtmlhead text="foobar">

#getCFHtmlHead()#
#resetCFHtmlHead()#[/code]
If you were to run that code, the JavaScript generated by CFAjaxProxy is outputted below the Hello World text and that the foobar bit is outputted directly below that. Normally the header content would have been in that order, but ABOVE the Hello World text. How does it work? The getPageContext() method gives you access to to the internal guts of your ColdFusion request. getOut() hands us the JspWriter class, and a quick loop climbs to the outermost JspWriter. For the clearHeaderBuffer function we call the initHeaderBuffer method to clear out the header buffer that tags like CFHTMLHead write into. For the getHeaderBuffer function, we pull out the headerBuffer field for CF7 and for CF8 we have to get both the prependHeaderBuffer and appendHeaderBuffer fields. When Adobe introduced the Ajax tags in CF8, they split out the header buffer into two fields so they could make sure the automatically generated JavaScript from those tags would come out ahead of any other JavaScript you put in CFHTMLHead. Since we are delving into some undocumented innards of your ColdFusion request, we aren't guaranteed that this code will work in future versions without modifications. I'm also not sure if it will work on a J2EE platform other than JRun. In case you're wondering why it takes so much code to access the fields and methods of the JSPWriter object, it is because it uses something called Java Reflection. Reflection lets you access private fields and methods for the sake of debugging, or fiddling with the object's internals. Generally this is something you want to be careful about doing. Also note, the above code does NOT work on OpenBD nor Railo. That is because they use different internal names for their classes and fields. What would be ideal is if Adobe, Railo, and OpenBD would place documented methods in the pageContext object to get the header buffer. If you're interested, the Model Glue code base has a OpenBD and Railo version of clearHeaderBuffer in their abstract remoting service. I know of no OpenBD or Railo version of getHeaderBuffer. I would write one, but I don't have an OpenBD or Railo server handy. Perhaps someone can volunteer.