The current version 1.20.3 saves 'rufus-3.4p.exe' in case 3. You are using an older Mingw32 version. Could you try the 1.20.3 version from https://eternallybored.org/misc/wget/ to make sure if it's a Mingw or a wget 1.20 issue !?

The cases 1+2 show an issue with long Location: headers that would create file names with more than 255 characters in length. As 255 seems to be your max file name length, wget tries to shorten these names too early. Wget also does not send Cookie: headers in the second HEAD request that are set in the 302 response before. This might be the reason for the 403 Forbidden.
This needs investigation.

GNU Wget2 (current master) does not have any of these issues. But i can't point you to an WIN32 executable.

Using Wget 1.20.

The --content-disposition option is not respected with long URLs.

Expected: download the file to the name from the Content-Disposition header.

Result: downloaded the filename with 240 characters of garbage that does not include the traits from Content-Disposition or the end of the URL which may have been able to be used to correct the filename afterwards.


Issue: GitHub is more and more using AWS for backend storage and AWS uses very long URLs with ugly parameterized output. Sadly, Wget trims the output URL to compose the filename even when a Content-Disposition header is included and the --content-disposition option is enabled.

This commonly results in 500+ character url-encoded filenames that are stripped down to 400-something, but since this includes slashes and semicolons, the resulting filename isn't valid, or is 240 characters and the relevant filename portion to be able to correct after download has stripped from the saved filename.

Ideally it should respect the filename exposed within the content-disposition header in order to prevent this problem.

If that's not an option, it should perform the character removals to "correct" the filename from the beginning of the filename and not from the end, to preserve the extension (or at least parsable data that could be used to identify the extension). Offering a trim option to select which side of the URL should be stripped would be an acceptable workaround temporarily.


Example requests:

wget -N --debug -e content_disposition=on https://github.com/pbatard/rufus/releases/download/v3.4/rufus-3.4p.exe

Results in "response1.txt"


wget -N --debug --content-disposition https://github.com/pbatard/rufus/releases/download/v3.4/rufus-3.4p.exe

Results in "response2.txt"


When using --content-disposition, these also send a pre-test HEAD request which can trigger duplicate downloads for servers that do not properly respond to HEAD requests (though that's not the case here).


Exclusion of the --content-disposition parameter results in the file downloading but not with the correct name.

wget -N --debug https://github.com/pbatard/rufus/releases/download/v3.4/rufus-3.4p.exe

Results in "response3.txt"