Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

HTTPS to HTTP redirect detection doesn't account for relative URIs in the Location header #38

Open
GGG-KILLER opened this issue Feb 19, 2021 · 0 comments

Comments

@GGG-KILLER
Copy link

Originally found in actions/setup-dotnet#110.

When fetching a shell script from the URL https://dot.net/v1/dotnet-install.sh in a test using @actions/http-client, there are 2 redirects involved:

  1. A 301 redirect from https://dot.net/v1/dotnet-install.sh to https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.sh;
  2. A 302 redirect from https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.sh to /download/dotnet/scripts/v1/dotnet-install.sh.

The second redirect fails with the following message:

Redirect from HTTPS to HTTP protocol. This downgrade is not allowed for security reasons. If you want to allow this behavior, set the allowRedirectDowngrade option to true.

However, there are no redirects from HTTPS to HTTP, just a redirect to a relative URI (which should preserve the HTTPS protocol).

The issue seems to be located in the following if:

http-client/index.ts

Lines 386 to 390 in edadda1

if (
parsedUrl.protocol == 'https:' &&
parsedUrl.protocol != parsedRedirectUrl.protocol &&
!this._allowRedirectDowngrade
) {

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@GGG-KILLER and others