Monday, August 23, 2010 1:50 PM
Having a strange problem on Windows 2003 32-bit server and WinHTTP.
I have a C/C++ application that uses WinHTTP that was working fine for many years. Today I encountered a strange situation while getting response from Apache/PHP application. WinHttpReadData returns a timeout error while reading the response. However, when executing the application under the debugger, I noticed, that, in fact, all data were read OK. The problem is caused by TCP connection closure. The situation is like this:
1. WinHTTP application POSTs request (some XML document).
2. PHP application responses OK with "Connection: close" and "Content-Length: 7508" headers.
3. WinHTTP reads all data successfully and I see TCP ACK that aknowledges all data in the MS Network Monitor.
4. This is where the problem starts. Nobody wants to close TCP connection. I can see various ACKs coming from WinHTTP and PHP until WinHTTP resets the connection and my application gets a timeout error. If I call WinHttpReadData with the buffer length that exactly match the Content-Length value, I get all the data successfully.
5. So, should WinHTTP terminate TCP connection after receiving all data declared in "Content-Length" header? Or it is a bug on the server side, since it sent "Connection: close" header?
I tried various options on WinHTTP side, like enabling and disabling Keep-Alive, but it doesn't change anything.
Thank you in advance.
- Moved by Qi Samuel ZhangMicrosoft Employee, Moderator Tuesday, February 22, 2011 4:35 AM (From:XML in Windows (MSXML and XmlLite))
Wednesday, August 25, 2010 9:03 AM
Monday, March 26, 2012 10:30 AM
I have the same problem with WinHTTP. Did you solve it?
Thanks in advance.
Wednesday, April 18, 2012 6:02 PM
I solved it by forcing the closer on my end, when I received the number of bytes provided in the Content-Length header. Normally, I would execute WinHttpReadData() until I get an empty return from it. However, this server (Apache) doesn't close the connection. So, I was waiting on ReadData() for a long time.