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 http://www.fusionlink.com -------------------------------------------------------------
