In your example it would be:
 <cfhttpparam type="header" name="xml" value="#payload.Trim()#"
encoded="no">

On Fri, Feb 18, 2011 at 3:19 PM, Steve Ross <[email protected]> wrote:

> Are you sure this param of type "xml" is right?
>
> CF ignores that when it is received... I wonder if your receiving service
> needs something like this instead? :
>
>                 <cfhttpparam type="header" name="xml" value="#foo#" >
>
>
> On Fri, Feb 18, 2011 at 3:07 PM, Steve Ross <[email protected]> wrote:
>
>> test cfm:
>>
>> <cffile action = "read" file =
>> "#GetDirectoryFromPath(GetCurrentTemplatePath())#test.xml" variable = "foo"
>> charset = "utf-8">
>>  <cfhttp method="post" url="http://url.to.your.site.com/test/receiver.cfm
>> ">
>>                  <cfhttpparam type="header" name="Content-Type"
>> value="application/atom+xml; charset=utf-8" />
>>                 <cfhttpparam type="header"
>> name="Content-transfer-encoding" value="text"/>
>>                 <cfhttpparam type="header" name="Accept"
>> value="application/atom+xml">
>>  <cfhttpparam type="Header" name="Accept-Encoding" value="*">
>> <cfhttpparam type="Header" name="TE" value="deflate;q=0">
>>                 <cfhttpparam type="xml" value="#foo#" encoded="no">
>> </cfhttp>
>>
>> receiver cfm:
>>
>> <cfsavecontent variable = "thedump">
>> <cfdump
>> var="#GetHttpRequestData()#"
>>  label="GetHttpResponseData() Values"
>> />
>> </cfsavecontent>
>>
>> <cffile action = "write" file =
>> "#GetDirectoryFromPath(GetCurrentTemplatePath())#/out.html" output =
>> "#thedump#" />
>>
>>
>> open "out.html" in your browser
>>
>>
>> On Fri, Feb 18, 2011 at 2:37 PM, Clarke Bishop 
>> <[email protected]>wrote:
>>
>>> To better understand how CFHTTP & CFHTTPParam work, I’m trying Steve’s
>>> idea to just call a local page to see what the header looks like.
>>>
>>>
>>>
>>> But the content is showing up as binary like this:
>>>
>>>
>>>
>>> *Content:HTTP Request Data - binary*
>>>
>>>
>>> 606312010910832118101114115105111110613449464834321011109911110010511010361341171161024556346362131060101110116114121321201091081101156134104116116112584747119119119461195146111114103475048485347651161111093462131032326011610511610810162841041051153210511532116104101321091051101051099710832981081111033211211111511632116105116108101604711610511610810162131032323232326097117116104111114621310323232323232326011097109101627411110411032681111016047110971091016213103232323232323260101109971051086210611110411010011110164101120971091121081014699111109604710110997105108621310323232323260479711711610411111462131032323232326011511710910997114121628410410511532105115321161041013210910511010510997108329810811110332112111115116321151171091099711412146604711511710910997114121621310323232323260991111101161011101163211612111210161341041161091083462841041051153210511532116104101321159710911210810132728477763299111110116101110116466047991111101161011101166213103232323232609997116101103111114121321161011141096134116971033211111010134324762131032323232326099971161011031111141213211610111410961341169710332116119111343247621310604710111011611412162
>>>
>>>
>>>
>>> I set Content-transfer-encoding=” text” but the data is still binary. I
>>> think it might be that it’s getting compressed.
>>>
>>>
>>>
>>> Here’s my code:
>>>
>>>
>>>
>>> <cfhttp method="post" url="#hsURL#">
>>>
>>>                 <cfhttpparam type="header" name="Content-Type"
>>> value="application/atom+xml; charset=utf-8" />
>>>
>>>                 <cfhttpparam type="header"
>>> name="Content-transfer-encoding" value="text"/>
>>>
>>>                 <cfhttpparam type="header" name="Accept"
>>> value="application/atom+xml">
>>>
>>> <cfhttpparam type="Header" name="Accept-Encoding" value="*">
>>>
>>> <cfhttpparam type="Header" name="TE" value="deflate;q=0">
>>>
>>>                 <cfhttpparam type="xml" value="#payload.Trim()#"
>>> encoded="no">
>>>
>>> </cfhttp>
>>>
>>>
>>>
>>> These lines are supposed to turn off compression:
>>>
>>> <cfhttpparam type="Header" name="Accept-Encoding" value="*">
>>>
>>> <cfhttpparam type="Header" name="TE" value="deflate;q=0">
>>>
>>>
>>>
>>>
>>>
>>> I also tried Charlie’s idea of adding the extra header values, but no
>>> luck there, either.
>>>
>>>
>>>
>>> Charlie, you said it … Grrrrrrrrrrrrrrrrrrrrr
>>>
>>>
>>>
>>>    Clarke
>>>
>>>
>>>
>>> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Charlie
>>> Arehart
>>> *Sent:* Friday, February 18, 2011 1:47 PM
>>> *To:* [email protected]
>>> *Subject:* RE: [ACFUG Discuss] Troubleshooting CFHTTP Webservice Call
>>>
>>>
>>>
>>> And consider also the function gethttprequestdata on that test page.
>>>
>>> Beyond that, the CFHTTP tag has proxy attributes. You may be able to
>>> configure that so they go through Charles or another proxy. Of course, this
>>> only works based on the assumption that the CF server dong the CFHTTP is
>>> indeed on your local dev box, as you say it is in your case.
>>>
>>> Finally, I have some thoughts I’d gathered up yesterday, but I was really
>>> opening that perhaps the XML type would solve the problem.
>>>
>>> While perhaps your attempts to “see” what CF is sending (whether with a
>>> proxy or on a test receiving page of your own), there may still just be
>>> issues with what you’re trying to call instead, and its expectations.  It’s
>>> indeed frustrating when trying to understand why a remote server doesn’t
>>> like what we send, and worse when (as in this case) it seems to complain
>>> that we’re sending something we would swear we’re not (in your case, it’s
>>> saying that you’re sending text/html when the header clearly tells it it’s
>>> atom). Grr. :-)
>>>
>>>
>>>
>>> I’m sure at some point someone will solve it and we’ll all look back
>>> smacking our foreheads at something we’re not seeing. :-)
>>>
>>> But until then, I can only offer a few thoughts from things I’ve found as
>>> I’ve looked around. I realize these don’t seem like they should solve the
>>> problem, but it’s easy enough to throw them in and at least rule out that
>>> they don’t help:
>>>
>>>
>>>
>>> - I found an example of a call I’d made to a restful web service, and I
>>> notice passed in the Accept which you’re not:  <cfhttpparam type="header"
>>> name="Accept" value="application/atom+xml">. Again, I realize that shouldn’t
>>> help the issue of what it thinks you’re *sending*.
>>>
>>> - I wonder if it may help to add the charset to the content-type, as in:
>>> <cfhttpparam type="header" name="Content-Type" value="application/atom+xml;
>>> charset=utf-8" />. Again, doesn’t seem it should be needed, but worth a
>>> shot.
>>>
>>> - I found a CF technote referring to how some atom-based services require
>>> a multiparttype/related  header, and CF defaults to using
>>> multipart/form-data. So a new attribute has been added to CFHTTP,
>>> multiparttype="related". For more info, see
>>> http://kb2.adobe.com/cps/406/kb406660.html (It appears the hotfix adds
>>> the attribute for CF 7 and 8, and it’s included in CF9.) Again, I realize it
>>> doesn’t seem related. Since you’re on CF8, I realize you may not want to
>>> bother with the hotfix for this one—unless of course you see something in
>>> the docs of what you’re calling that may say it needs you to send as
>>> multipart/related.
>>>
>>>
>>>
>>> /charlie
>>>
>>>
>>>
>>> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Steve
>>> Ross
>>> *Sent:* Friday, February 18, 2011 11:04 AM
>>> *To:* [email protected]
>>> *Subject:* Re: [ACFUG Discuss] Troubleshooting CFHTTP Webservice Call
>>>
>>>
>>>
>>> To see what CFHTTP is doing send a request to another cfm locally on your
>>> box and dump the incoming request.
>>>
>>>
>>>
>>> -Steve
>>>
>>> On Fri, Feb 18, 2011 at 10:59 AM, Clarke Bishop <
>>> [email protected]> wrote:
>>>
>>> Thanks Charlie. I did try type=”xml” like you suggested, but it didn’t
>>> help.
>>>
>>> I think I need to better understand how CFHTTP/CFHTTPParam translate into
>>> HTTP headers. I know what I want the request to look like, but how to make
>>> CF create that request is my challenge.
>>>
>>> 1.       Do you or anyone else know of any good examples or links for
>>> how CF builds requests?
>>>
>>> 2.       Also, I still haven’t been able to get Charles to work with my
>>> CF development server. Does anyone have any examples or links for how to
>>> setup Charles to show HTTP traffic from a CFHTTP. Charles has HTTP proxy and
>>> SOCKS proxy options – Which one is better to use? And, what’s the best way
>>> to get CF to route through the proxy?
>>>
>>> Right now, I’m kind of stuck, so I really appreciate any ideas!
>>>
>>>    Clarke
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by FusionLink <http://www.fusionlink.com>
>>> -------------------------------------------------------------
>>>
>>> -------------------------------------------------------------
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by FusionLink <http://www.fusionlink.com>
>>> -------------------------------------------------------------
>>>
>>
>>
>>
>> --
>> Steve Ross
>> web application & interface developer
>> http://blog.stevensross.com
>> [mobile] (912) 344-8113
>> [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]
>>
>
>
>
> --
> Steve Ross
> web application & interface developer
> http://blog.stevensross.com
> [mobile] (912) 344-8113
> [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]
>



-- 
Steve Ross
web application & interface developer
http://blog.stevensross.com
[mobile] (912) 344-8113
[ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]

Reply via email to