CFHTTP weirdness - Connection Timeout

I'm trying to use CFHTTP to capture a simple XML file from a remote server - <cfhttp url="http://64.119.37.62/xml" method="GET" timeout="10"> When I try to access the #cfhttp.filecontent# is shows only "Connection Timeout". However, I can access the file from a browser on the server, the cfhttp.errorDetail is empty, the cfhttp.statusCode is 200, the mimeType is being picked up correctly, and if I sniff the packets I see the entire file is send to CF. And if I set the path and file attributes of CFHTTP, the XML file is saved successfully to my server. So why is #cfhttp.filecontent# broken? It only does this for some sites. With most of them, everything works fine, but with this site and others like it, CF is choking on the content somewhere. I have tried setting the character set, setting user-agent, setting the Accept-Encoding and TE headers to "deflate;q=0" to solve any compression issues, and about everything else I can think of. Can anyone else try to CFHTTP that file (http://64.119.37.62/xml) and see if it works? This is a FRESH install of MX 7. Frustrated! Jared

this worked for me <cfhttp method="get" url="http://64.119.37.62/xml" result="web"> <cfdump var="#web#"> FileContent: <?xml version="1.0"?> <FSHost> <ServerName>West Coast ATC - 24HR 1</ServerName> ... </FlightPlan> </FlightPlans> </FSHost> ----- Excess quoted text cut - see Original Post for more -----

> this worked for me > <cfhttp method="get" url="http://64.119.37.62/xml" result="web"> > <cfdump var="#web#"> Thanks. This is so frustrating. This used to work fine, but suddenly stopped a few months ago. I've even formatted, fresh reinstalled Windows, and upgraded from 6.1 to MX 7 and the problem continues - primarily with sites that provide that XML file. Other sites tend to work fine. Your exact code will execute the dump as follows for me: Charset: [empty string] ErrorDetail: [empty string] Filecontent: Connection Timeout Header: HTTP/1.1 200 OK Content-type: text/xml Pragma: no-cache Cache-Control: no-cache Mimetype: text/xml Responseheader [ Cache-Control: no-cache Content-type: text/xml Explanation: OK Http_Version: HTTP/1.1 Pragma: no-cache Status_Code: 200 Statuscode: 200 OK ] Text: YES I guess I could use CFHTTP to write the file to disk, then use CFFILE to open it, but that is WAY more overhead than I want. I'd much rather just get CFHTTP working like it's supposed to. :-( Any other ideas?

try running your ColdFusion servers with the same account your are logging onto the server with ----- Excess quoted text cut - see Original Post for more -----

that should be CF Service ----- Excess quoted text cut - see Original Post for more -----

Thanks for your responses. No joy yet. AJ Mercer wrote: > try running your ColdFusion servers with the same account your are logging > onto the server with Tried this with an administrator account and the problem remains. Tom Chiverton wrote: > Trying setting an explicit return variable to save into. I'm assuming you mean <cfhttp result="myvar">. I've done that and then <cfdump>ed the myvar variable. Everything looks fine (200 status code, correct mime type, full headers) except Filecontent still shows Connection Timeout. Randy Johnson wrote: > Have you tried setting the timeout to a higher number? Yes. I've tried VERY high numbers and no timeout at all. I should note, that the full timeout period is used before I get anything on screen. However, when I cfhttp to a file, everything runs and the the file shows up almost instantly every time. There's something breaking between when CF gets the remote data and when it creates the Filecontent data. Jared

In looking further at the headers, I've found that the content-length header is not provided by the server I'm accessing. This shouldn't be a big deal as the remote server indicates when the transmission is done. But when the remote server sends the FINISH flag to Coldfusion, CF does not terminate the connection as my web browser does. CF isn't responding when the remote server terminates the connection. It acknowledges the command, but doesn't actually close the connection like it should. This sure seems like a bug in CF to me. Is there any way around this or any way to get CF to support the HTTP protocol correctly?

----- Excess quoted text cut - see Original Post for more ----- Hi Jared Did you ever get to the bottom of this. I've got the same issue with CF9/IIS7/Vista. Dave

sounds like you need to terminate the connection with CF when the FINISH flag is returned irrespective of the content length.... I'm not sure how you'd do this with coldfusion but I'd imagine it was possible.. I hope you find the answer as this appears to be a very legitimate problem with cfhttp. Andrew. ----- Excess quoted text cut - see Original Post for more -----

> However, I can access the file from a browser on the server, the > cfhttp.errorDetail is empty, the cfhttp.statusCode is 200, the > mimeType is being picked up correctly, and if I sniff the packets I > see the entire file is send to CF. And if I set the path and file > attributes of CFHTTP, the XML file is saved successfully to my server. > So why is #cfhttp.filecontent# broken? Trying setting an explicit return variable to save into. -- Tom Chiverton Helping to globally integrate high-end technologies on: http://thefalken.livejournal.com **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF.  A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged.  If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents.   If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com.

Hi Jared, Have you tried setting the timeout to a higher number? -Randy Jared Smith wrote: ----- Excess quoted text cut - see Original Post for more -----