You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Invoke-WebRequest allow option to preserve orginal filename (even after redirect) #9742
As a user downloading from an aka.ms URL, I want the filename of my downloaded file to automatically match that of the source file.
E.g. on Linux, if I do
wget https://aka.ms/downloadazcopy-v10-linux
It just works. The output file is created, and it has the right name. E.g. when the aka.ms link points to a file name AzCopy_linux-amd64-10.0.9.tar.gz, that's the name I end up with on disk. When someone updates the aka ms link to point to, say AzCopy_linux-amd64-10.2.0.tar.gz, then I can run the same command as before, and this time I automatically get the updated name.
This is useful for cases where the filename conveys useful information (such as the version).
But in PowerShell, I can't automatically use the file's existing name. I have to specify a name. But because the URL is a redirect, via aka.ms, I don't actually know the name of the download file in advance. So I can't specify a meaningful name (e.g. I can't include the version number). I still get the file, but I lose any information that was in its original name
I've looked at this and decided that the Web Cmdlets would actually suffer in usability trying to add this. I can't find the issue, but this this is a duplicate of a closed issue. The web cmdlets are just not meant for downloading. They are meant for response body processing.
Instead, some of the wget/curl functionality will be implimented in a new cmdlet where this exact scenario will be addressed.
John Rusk (@JohnRusk), I think your suggestion makes perfect sense and has come up repeatedly; adding this functionality as an experimental feature first has been green-lit: see #11671 (comment)
Activity
markekraus commentedon May 27, 2019
I've looked at this and decided that the Web Cmdlets would actually suffer in usability trying to add this. I can't find the issue, but this this is a duplicate of a closed issue. The web cmdlets are just not meant for downloading. They are meant for response body processing.
Instead, some of the wget/curl functionality will be implimented in a new cmdlet where this exact scenario will be addressed.
markekraus commentedon May 27, 2019
Please comment on PowerShell/PowerShell-RFC#124 instead.
mklement0 commentedon Mar 1, 2020
John Rusk (@JohnRusk), I think your suggestion makes perfect sense and has come up repeatedly; adding this functionality as an experimental feature first has been green-lit: see #11671 (comment)