Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IdHttp.ReadTimeout has no affect on Android when https fails
#1
My DSL ISP had a weird outage the last 2 days.
Accessing https sites did not work, while http worked fine. Also tls did not work like in SMTP StartTls.
I disabled StartTls and then could send emails.
I have not understood the actual reason, but took that rare opportunity to check my FMX apps.

It uses TIdHTTP accessing a https webpage
I already had set ConnectTimeout:= 2000;
but it still blocked.
Setting ReadTimeout:= 8000; helped, it timed out after 11 sec. It was always 3 sec longer than ReadTimeout.
Perfect on Windows!

But on Android ReadTimeout did not help , it still blocked forever.

I tried Berlin (Indy 10.6.2.5341) and Seattle (Indy 10.6.2.5467)

Q:
Is there a solution to get a timeout on Android?

Unfortunately I can't test this scenario anymore, my ISP now works normally again
Reply
#2
(09-07-2019, 03:01 PM)JayBart Wrote: It uses TIdHTTP accessing a https webpage
I already had set ConnectTimeout:= 2000;
but it still blocked.

The ConnectTimeout is applied only when the socket is actually making the TCP connection to the destination IP address. It does not take into account the time needed to resolve a hostname into an IP address, that is always a blocking operation. Unless you perform your own lookup using TIdDNSResolver or platform-specific API that supports doing the lookup with a timeout.

Have you tried using a packet sniffer/debugger, like Wireshark or Fiddler, to see exactly what stage your client is blocking at? Is it during the TCP handshake? The TLS handshake? The HTTP request/response?

(09-07-2019, 03:01 PM)JayBart Wrote: Setting ReadTimeout:= 8000; helped, it timed out after 11 sec. It was always 3 sec longer than ReadTimeout.
Perfect on Windows!

The ReadTimeout is applied only after the TCP connection is fully established and the TLS handshake is complete, when actually reading application data from the connection.

Note: on Windows only, TIdSSLIOHandlerSocketOpenSSL does force socket-level timeouts via the socket's SO_RCVTIMEO and SO_SNDTIMEO options. It does not do that on other platforms.

(09-07-2019, 03:01 PM)JayBart Wrote: But on Android ReadTimeout did not help , it still blocked forever.

Then most likely the TCP connection, or the TLS handshake, is not fully completing. You need to figure out which.

(09-07-2019, 03:01 PM)JayBart Wrote: I tried Berlin (Indy 10.6.2.5341) and Seattle (Indy 10.6.2.5467)

The current Indy version is 10.6.2.5517.

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)