When a HTTP "fatal" error is encountered, such as a hostname resolution failure, HTTP downloads are supposed to be disabled entirely. However, despite that, HTTP downloads were still attempted.
The sequence of events is the following:
HTTP_RunDownloads calls process_downloads
In process_downloads, a DNS error is detected, causing fatal_error to be indicated, and abort_downloads called
HTTP_CleanupDownloads() is called, which cleans up curl_multi
However, after exiting process_downloads(), start_next_download() is called, which happily starts a new CURL download ... which is never checked for completion, as any subsequent HTTP_RunDownloads call will exit early.
The solution I opted for was to add check for curl_multi in start_next_download(). Another idea might be to check for curl_multi right before the start_next_download() call in HTTP_RunDownloads().
To reproduce the issue, find a server with a map or files you don't have (so a download is triggered) and provoke a DNS failure, eg by hacking in a bogus HTTP server name.
When a HTTP "fatal" error is encountered, such as a hostname resolution failure, HTTP downloads are supposed to be disabled entirely. However, despite that, HTTP downloads were still attempted.
The sequence of events is the following:
HTTP_RunDownloads
callsprocess_downloads
process_downloads
, a DNS error is detected, causingfatal_error
to be indicated, andabort_downloads
calledHTTP_CleanupDownloads()
is called, which cleans upcurl_multi
process_downloads()
,start_next_download()
is called, which happily starts a new CURL download ... which is never checked for completion, as any subsequentHTTP_RunDownloads
call will exit early.The solution I opted for was to add check for
curl_multi
instart_next_download()
. Another idea might be to check forcurl_multi
right before thestart_next_download()
call inHTTP_RunDownloads()
.To reproduce the issue, find a server with a map or files you don't have (so a download is triggered) and provoke a DNS failure, eg by hacking in a bogus HTTP server name.