1

I'm developing a Delphi application to download files using both WinHTTP (via direct API calls) and TNetHTTPClient. Everything works fine on most networks, but on one specific open Wi-Fi network, both approaches fail consistently with a timeout.

Specifically:

  • WinHttpSendRequest returns error

    12002 (ERROR_WINHTTP_TIMEOUT)

  • TNetHTTPClient.Get() also raises a timeout exception
  • However:
    • Indy (TIdHTTP) downloads the file successfully on the same network,
    • and Chrome or IDM can also download the file immediately.

The target URL is hosted on Cloudflare R2, with no enforced bot protection, and works fine from other networks.

What I’ve already tried:

  • mimicked common browser headers like User-Agent, Accept, etc.
  • ensured SNI and TLS version compatibility
  • tried both WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY and WINHTTP_ACCESS_TYPE_NO_PROXY, but the result is the same — still getting timeout (error 12002 in WinHTTP).
  • I also inspected the traffic using Wireshark. When the download fails (using WinHTTP or TNetHTTPClient), I do not see any DNS resolution phase in the capture. However, when switching to another network or using Indy or web browsers (which successfully download the file), I can clearly observe the DNS resolution phase.

Question: Why would WinHTTP and TNetHTTPClient time out on one specific network, while Indy and browsers succeed? Is there any internal behavior in WinHTTP that makes it more sensitive to certain network environments (e.g., open Wi-Fi, captive portals, DNS behavior, SNI, etc.)?

Update:

I confirmed that WinInet also experiences the same issue on this network. The problem was resolved by enabling the WINHTTP_OPTION_IPV6_FAST_FALLBACK option in WinHTTP, which allowed the client to quickly fall back to IPv4 when IPv6 was slow or unresponsive.

Improve this question
New contributor
sudormrf is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
3
  • The missing DNS resolving can be a coincidence of caching, tho. Open Wi-Fi networks are prone to be restricted/censored, so selected websites/hosts and services are not available. From another perspective the website of interest might also reject requests from certain networks (like VPNs)/providers (non-ISPs)/clients (like Java in general or wget). I doubt you're able to fully mimick one of the major HTTP clients (at least your code is missing for that).
    – AmigoJack
    Commented 2 days ago
  • @AmigoJack There is no need to mimic a browser client — even Indy (TIdHTTP) doesn't emulate one, yet it works correctly. On the problematic open Wi-Fi network, I can still connect to other servers without any issues. The problem only occurs with WinHTTP and TNetHTTPClient, both timing out on certain hosts, even though other HTTP clients succeed.
    – sudormrf
    Commented 2 days ago
  • Write your Update as an answer. If you have no answer to your question there is a risk community bot deleting it after several month.
    – fisi-pjm
    Commented 1 hour ago
Related questions
3
wininet or winhttp, which is preferred for POST requests
9
How to download a file over HTTPS using Indy 10 and OpenSSL?
1
Delphi Client connecting to HTTPS - TRestRequest.Execute a lot slower than TIdHttp.Post
Load 5 more related questions Show fewer related questions

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.