PowerShell binary does not have a permanent location

Created on 23 Jul 2020  ·  24Comments  ·  Source: PowerShell/PowerShell

Steps to reproduce

iwr 'http://github-production-release-asset-2e65be.s3.amazonaws.com/49609581/e915ff00-c752-11ea-9e99-dd5d102586b5?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200722%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200722T213122Z&X-Amz-Expires=300&X-Amz-Signature=1cbd44c1fb03c3a2c9d60faecd56e27d49c50e5b974db094e2cc2f429e548736&X-Amz-SignedHeaders=host&actor_id=1363094&repo_id=49609581&response-content-disposition=attachment%3B%20filename%3DPowerShell-7.0.3-win-x64.msi&response-content-type=application%2Foctet-stream' -RESUME -OUTFILE:'PowerShell-7.0.3-win-x64.msi'

Expected behavior

Download continues.

Actual behavior

Invoke-WebRequest:
AccessDeniedRequest has expired3002020-07-22T21:36:22Z2020-07-23T06:07:53Z066EDD1631667542zvP/u8SwEw7yMlpYirurvu329u4W0kk71TvVyVjdncx1f7CLYBQWpOPy+u28DsJY7NTr88sorWM=

Note also how the error message is malformed (by IWR itself, not by AWS).

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.2
PSEdition                      Core
GitCommitId                    7.0.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
Area-Maintainers-Build Issue-Question Resolution-External

All 24 comments

I tried X-Amz-Date=20200723T063122Z:

AuthorizationQueryParametersErrorInvalid credential date "20200722". This date is not the same as X-Amz-Date: "20200723"

I tried removing X-Amz-Expires:

Query-string authentication version 4 requires the X-Amz-Algorithm, X-Amz-Credential, X-Amz-Signature, X-Amz-Date, X-Amz-SignedHeaders, and X-Amz-Expires parameters.

I tried X-Amz-Expires=38400:

The request signature we calculated does not match the signature you provided.

Why are we protecting this so avidly? Could we make this X-Amz-Expires much longer?

And, last but not least, why doesn’t Invoke-WebRequest infer $OutFile from Content-Name like all decent user agents do?
Answer: https://github.com/PowerShell/PowerShell/issues/11671#issuecomment-578904101

To make things a bit clearer, when the browser starts downloading the file. it remembers its _true_ location, not its _declared_ location. If that true location becomes invalid, which it unfortunately does, the browser cannot resume the download. I am afraid the same goes for IWR. (Aside: IWR reports the numbers of bytes processed in the _current_ download session, not including the _total_ number of bytes processed, which is unexpected and frustrating.)

why doesn’t Invoke-WebRequest infer $OutFile from Content-Name like all decent user agents do?

It seems we have an issue for this.

This is about improper release publication, IWR was called just to illustrate the steps I have taken to rescue the situation (and all of them failed).

What do the source URL from?

The URL is from the download manager in Microsoft Edge.

I ask about source - which web page contains this link?

Asking about referrer? This URL is not referred to by a link, is a redirect handed out by the server, it is not placed on any page (except for this very issue but I have taken every precaution not to make it a regular link). And except for the download manager in the browser, which is also a page but it is not exactly a Web page because it is only available to me.

I wonder why you use redirected URL instead of regular link like https://github.com/PowerShell/PowerShell/releases/download/v7.0.3/PowerShell-7.0.3-win-x64.msi

I used the regular link, I found myself facing the true locator. This is how Microsoft have implemented their download manager.

Resume download not working in Edge browser?

Nope, and the error message is "Failed". Go figure.

Thanks for clarify!

I guess it is common problem for all links on Amazon storage. We can not fix this in the PowerShell repository. You need to report on other MSFT resources like forums or UserVoice site to communicate with MSFT Edge browser team, or use your support contract.

The official URL is here and we can at least change the contract with Amazon storage so that the resulting redirected URL will be valid much longer. Moreover, this product is still under Microsoft’s auspices, so we could ask Microsoft to serve our releases, maybe as a back-up URL.

we could ask Microsoft to serve our releases

It is GitHub site link and it is for GiHub support. I guess you will see the same in other GitHub repositories too.

I do not think any support is needed. See Managing releases in a repository — GitHub Docs.

We don't create the link manually. GitHub creates the link.

Cannot resume download of artifact release redirects
This does not mean that we cannot ask Microsoft to store our releases in more reliable locations.

Sure, but it does mean it's solidly outside the purview of an individual repository.

@yecril71pl Thanks for open issue in GitHub support.

Sure, but it does mean it's solidly outside the purview of an individual repository.

The GitHub problem is, finding an alternate location is not. I mean, if this is to become THE shell, it should at least be downloadable 😁

It is, for the vast majority of users. If you specifically are seeing issues with a ~50mb download taking long enough to require resume support, I would recommend consulting with your ISP as to why their service is preventing your operations.

If you have specific suggestions for alternatives, the PS team can discuss them with you and triage appropriately. Vague suggestions won't get far; the number of alternatives is too numerous to reasonably enumerate.

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

Was this page helpful?
0 / 5 - 0 ratings