idHTTP Timeout Bug

[wolfgang@koeppner-bures.at]

Hello again!
 I found an issue with idHTTP.Post when a ReadTimeout occurs. It seems to me, that I might receive the DELAYED answer from the previous timeout in the NEXT call to idHTTP.Post!!

This has cost me ours of searching but look at this piece of transactions:

First Post:

• Ges 05.01.2020 12:04:04: POST /?token=**************************** HTTP/1.1<EOL>Content-Type: application/json; charset=ISO-8859-1<EOL>Content-Length: 173<EOL>Host: eu-wap.tplinkcloud.com<EOL>Accept: application/json<EOL>User-Agent: SmartFlat<EOL><EOL>
  
• Ges 05.01.2020 12:04:04: {"method":"passthrough","params":{"deviceId":"8006EEBA62D94CECE697137CA53C08D21A2EB65B","requestData":"{\"system\":{\"get_sysinfo\":{\"emeter\":{\"get_realtime\":\"\"}}}}"}}
  

*TIMEOUT HERE*
Second Post:

• Ges 05.01.2020 12:04:06: POST /?token=**************************** HTTP/1.1<EOL>Content-Type: application/json; charset=ISO-8859-1<EOL>Content-Length: 173<EOL>Host: eu-wap.tplinkcloud.com<EOL>Accept: application/json<EOL>User-Agent: SmartFlat<EOL><EOL>
  
• Ges 05.01.2020 12:04:06: {"method":"passthrough","params":{"deviceId":"80062655216E1D3000B50BA9B79BEB8319611FB8","requestData":"{\"system\":{\"get_sysinfo\":{\"emeter\":{\"get_realtime\":\"\"}}}}"}}
  

Reply:

• Erh 05.01.2020 12:04:07: HTTP/1.1 200 <EOL>Content-Type: application/json;charset=UTF-8<EOL>Date: Sun, 05 Jan 2020 11:04:01 GMT<EOL>Content-Length: 712<EOL>Connection: keep-alive<EOL><EOL>{"error_code":0,"result":{"responseData":"{\"system\":{\"get_sysinfo\":{\"sw_ver\":\"1.5.4 Build 180815 Rel.121440\",\"hw_ver\":\"2.0\",\"type\":\"IOT.SMARTPLUGSWITCH\",\"model\":\"HS100(EU)\",\"mac\":\"AC:84:C6:9C:9C:01\",\"dev_name\":\"Smart Wi-Fi Plug\",\"alias\":\"Calypso\",\"relay_state\":1,\"on_time\":7449,\"active_mode\":\"none\",\"feature\":\"TIM\",\"updating\":0,\"icon_hash\":\"\",\"rssi\":-56,\"led_off\":0,\"longitude_i\":163303,\"latitude_i\":482313,\"hwId\":\"A8D378F10FACF73C85F72B445B654AB1\",\"fwId\":\"00000000000000000000000000000000\",\"deviceId\":\"8006EEBA62D94CECE697137CA53C08D21A2EB65B\",\"oemId\":\"0CC41572446631ACD46A8EDFC8942AE1\",\"next_action\":{\"type\":-1},\"err_code\":0}}}"}}
  

This didnt happen when I was using the WinINET API so I dont think this is a device-bug...

Any comments, ideas?

[rlebeau]

If a read timeout occurs, the socket is in an indeterminate state, so you need to stop using it. Call TIdHTTP.Disconnect() and empty the TIdHTTP.IOHandler.InputBuffer (if TIdHTTP does not do this automatically) so that TIdHTTP will send the next request using a new TCP socket.

[wolfgang@koeppner-bures.at]

If a read timeout occurs, the socket is in an indeterminate state, so you need to stop using it.  Call TIdHTTP.Disconnect() and empty the TIdHTTP.IOHandler.InputBuffer (if TIdHTTP does not do this automatically) so that TIdHTTP will send the next request using a new TCP socket.

I didnt think that I need to take care of this, but I've added it to my code. Thx for the hint!
We'll see... :-)

[rlebeau]

I didnt think that I need to take care of this

Ideally, you shouldn't need to. I don't recall whether TIdHTTP actually handles this or not. If you feel like this is a bug that needs fixing, feel free to submit a bug report.

[wolfgang@koeppner-bures.at]

I didnt think that I need to take care of this

Ideally, you shouldn't need to.  I don't recall whether TIdHTTP actually handles this or not.  If you feel like this is a bug that needs fixing, feel free to submit a bug report.

as far as I can see it now, that change didnt change anything.
I'll dig in a bit further.

[rlebeau]

as far as I can see it now, that change didnt change anything.

It should have, given you seem to be having an issue with lingering data, and I suggested flushing lingering data from memory. Unless the problem is actually on the server side and it is holding on to stale data after the timeout occurs and sending it on the next request. Did you check with a network sniffer whether the stale data is actually on the wire or not? If it is, then this becomes a server issue rather than an Indy issue.

---

Have you converted the certs to the proper format or used the proper variants?

What does that have to do with this issue? Maybe you meant to post that in this discussion instead?

[wolfgang@koeppner-bures.at]

ok, forget it, it's working now. I somehow had the wrong KEY!