IdHttp.ReadTimeout has no affect on Android when https fails

[JayBart]

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

[rlebeau]

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?

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.

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.

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

The current Indy version is 10.6.2.5517.

[JayBart]

Sorry for the very late reply. I didn't get an email alert and assumed that there was no reply.

Since my ISP is now working again, I can't check that situation anymore.
I assume the problem was that TCP msg were not forwarded anymore when a certain size got exceeded. I noticed it when typing manually POP3 commands. With the LIST cmd I got replies when there were 10-50 emails waiting, but when it grew further the server reply did not get thru to me. So now I assume that TLS handshake msg also were larger and thus failed. I also noticed that small sizes http webpages were shown on the browser, but not larger size html-files.

Unfortunately I had not set up Wireshark for Android traffic, now I'm better prepared. I guess I will never see this ISP problem again.