Bug #5481


HTML Status Codes not Processed Properly from download_file

Added by Daniel Subert about 6 years ago. Updated almost 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


The download_file function returns status codes as true if 200, or the status code if another value. However, this is then used in if functions poorly and sometimes not checked at all before calling other functions relying on the file downloaded. The problem is that status codes are not 0 so an if(download_file(...)) will always evaluate true, even for a 404 not found or 401 forbidden.

download_file should only return the status code, and should always be checked for the code to be successful according to

The function download_file also does not handle a curl error, so if a status 200 download fails in the middle of downloading the file, the file can still be processed.

If would suggest returning http errors as positive numbers and curl errors as negative numbers to differentiate the type of error and processing the errors properly in every location this function is used. Then you can use
$result = download_file(...);
if($result matches as success code) {}
else { process $result error code }

This issue is marked Very High as the firmware and package download uses this function to update pfSense.

Actions #1

Updated by Chris Buechler about 6 years ago

  • Status changed from New to Confirmed
  • Priority changed from Very High to Normal

it's no longer used for package or update downloads in 2.3. The only thing that uses it in 2.3 is alias downloads. Those should have better validation though.

Actions #2

Updated by Jim Thompson almost 6 years ago

  • Assignee set to Renato Botelho
Actions #3

Updated by Chris Buechler almost 6 years ago

  • Status changed from Confirmed to Duplicate
  • Target version deleted (Future)
  • Affected Version deleted (All)

I fixed this in #5848


Also available in: Atom PDF