[browser][http] Add support for AllowAutoRedirect.

[kjpou1]

Right now the property AllowAutoRedirect throws Platform Not Supported Exception trying to access this parameter.

• Add property support for SupportsRedirectConfiguration, AllowAutoRedirect.
• Property MaxAutomaticRedirections still throws PNSE as per comments below. Leaving it at Platform Not Supported Exception since it is not supported by platform fetch api. It may be confusing to see this set and fetch not respecting the value.

---

The fetch api supports three values for redirection and transparently follows HTTP-redirects, like 301, 302 etc.

• The redirect option allows to change that:

  • "follow" – the default, follow HTTP-redirects,
  • "error" – error in case of HTTP-redirect,
  • "manual" – don’t follow HTTP-redirect, but response.url will be the new URL, and response.redirected will be true, so that we can perform the redirect manually to the new URL (if needed).

Note
The manual value above does not really follow what the documentation says. See issue Cannot get next URL for redirect="manual" another issue pertaining to this issue is Header to opt out of opaque redirect .

---

This PR will set the redirect property on the request object to manual if AllowAutoRedirect is false:

• This stops the automatic redirection
• Sets the HttpResponseMessage as follow:

response message: StatusCode: 0, ReasonPhrase: 'opaqueredirect', Version: 1.1, Content: System.Net.Http.BrowserHttpHandler+BrowserHttpContent, Headers:
{
   Content-Length: 0
}

One way to handle the redirect manually is checking the response message IsSuccessStatusCode is false and the ReasonPhrase is opaqueredirect.

As per the issue that is referenced the next URL is not modified to the the next URL location.

sample output from simulated test:

Response {type: "opaqueredirect", url: "https://localhost:6001/WeatherForecast/GetRedirect", redirected: false, status: 0, ok: false, …}
body: null
bodyUsed: false
headers: Headers {}
ok: false
redirected: false
status: 0
statusText: ""
type: "opaqueredirect"
url: "https://localhost:6001/WeatherForecast/GetRedirect"

---

If trying to set the AllowAutoRedirect after any request has been made then the following error is thrown:

 (index):1 Uncaught (in promise) System.AggregateException: One or more errors occurred. (This instance has already started one or more requests. Properties can only be modified before sending the first request.)
  ---> System.InvalidOperationException: This instance has already started one or more requests. Properties can only be modified before sending the first request.
    at System.Net.Http.BrowserHttpHandler.CheckDisposedOrStarted()
    at System.Net.Http.BrowserHttpHandler.set_AllowAutoRedirect(Boolean value)
    at System.Net.Http.HttpClientHandler.set_AllowAutoRedirect(Boolean value)
    at WasmHttpClientTest.Client.HttpClientRequestAsync(String url)
    --- End of inner exception stack trace ---

---

There are a number of differences when using the fetch api that does not line up with the dotnet core implementation.

Implementation summary:

• Fix the issue of PNSE in existing code when using AllowAutoRedirect. A better way would have been checking the property SupportsRedirectConfiguration as it returned false before this PR. Attempted Use With Blazor wasm return "Property AllowAutoRedirect is not supported." octokit/octokit.net#2188

• Allow the Get or Post of the HttpClient to not follow a redirect. As per the issue [wasm] Blazor 303 responses, and fetch vs navigation #39365

• What is different from dotnet core AllowAutoRedirect:

  • The fetch API does not return a status code. Cannot get next URL for redirect="manual". Instead of faking a 3XX status code the implementation uses the ReasonPhrase to return the fetch response type opaqueredirect.

  • The fetch API does not return the next URL of the redirect. atomic-http-redirect-handling which basically says that it is implemented that way to block cross-site scripting attack.

• One way to handle the redirect manually is checking the response message IsSuccessStatusCode is false and the ReasonPhrase is opaqueredirect.

---

References:

• whatwg/fetch#763
• atomic-http-redirect-handling
• GoogleChromeLabs/sw-precache#220
• https://fetch.spec.whatwg.org/#concept-request-redirect-mode

---

Close: #41255
Close: #39365

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[kjpou1]

/cc @mkArtakMSFT @pranavkm just wanted to make sure you guys saw this in case you want to weigh in on it.

[marek-safar]

@karelz who could review this part? Should we try harder to map the result to status codes or expose that differently to the developers?

[kjpou1]

Hello everyone. Is there any update on this?

/cc @marek-safar @karelz @ManickaP

[kjpou1]

Also there is a line in the PR comments about mapping a result and the approach for this PR:

Instead of faking a 3XX status code the implementation uses the ReasonPhrase to return the fetch response type opaqueredirect.

[scalablecory]

CC @dotnet/ncl

Hrm this is an interesting one. It seems like there is not a perfect solution here -- fetch API seems poorly made. ¯\_(ツ)_/¯

Without setting a normal redirect status code, we break compat with any existing code handling redirects.

But, it seems wrong to fake a status code when we don't know what the actual status code was. If we were to fake a status code, a temporary redirect seems like the best choice -- permanent redirect could cause dangerous handling e.g. updating a URI in a database.

To add a third bad option, what do we think of this? It at least gives the user some flexibility here.

public class BrowserHttpHandler
{
    public const HttpStatusCode OpaqueRedirect = (HttpStatusCode)1000;

    // if false, return TemporaryRedirect. if true, return OpaqueRedirect.
    public bool ReturnOpaqueRedirect { get; set; } = false;
}

(note, using a status code like this may not be advisable as an on-by-default option, as you might have some code doing e.g. if(StatusCode >= 500))

[kjpou1]

If I am understanding the above wouldn't this change the Public API as well?

[geoffkizer]

Just to be clear -- since the fetch API does not give you the redirect URL, even with 'manual', there's basically nothing you can do with a redirect result other than know that it was a redirect, right?

So any existing code that wants to handle redirects manually is going to be broken anyway.

As such I'm fine just indicating the redirect via the ReasonPhrase, as originally proposed. It seems like fetch basically gives you two options, either auto-follow redirects, or don't handle redirects at all.

[scalablecory]

Just to be clear -- since the fetch API does not give you the redirect URL, even with 'manual', there's basically nothing you can do with a redirect result other than know that it was a redirect, right?

It seems to be used very little, I'm having trouble finding an exact answer, but some places indicate that manual redirect will still fill response.url.

Otherwise I'm not sure how it would be different from 'error`. @marek-safar can you clarify?

[kjpou1]

@scalablecory The only case to go on is the issue Cannot get next URL for redirect="manual" that is closed on the actual fetch implementation repo which is what browsers actually use.

There is another issue labeled as Clarify "manual" redirect mode . Maybe that helps to clarify as It actually specifies the following:

"manual"

Retrieves an opaque-redirect filtered response when a request is met with a redirect, to allow a service worker to replay the redirect offline. The response is otherwise indistinguishable from a network error, to not violate atomic HTTP redirect handling.

[kjpou1]

Just to follow up. If one uses error then an uncatchable error will be thrown in the browser with no relative/usable information being able to be captured.

[kjpou1]

It seems to be used very little, I'm having trouble finding an exact answer, but some places indicate that manual redirect will still fill response.url.

My problem with adding code for this if it does work in some browsers and not others was to have a consistent interface at the least. If one browser work and another does not it will just cause even more confusion to the user. At least this way manual is "broken" consistently across browsers.

[scalablecory]

Okay, if "manual" is not giving consistent useful information across browsers, I guess setting the reason phrase is fine. It seems like it has a use that only makes sense in the browser, so portability is not a concern.

[ManickaP]

since @scalablecory is fine with it

[kjpou1]

Thanks everyone

[dazinator]

It seems like fetch basically gives you two options, either auto-follow redirects, or don't handle redirects at all.

In a blazor scenario using http client, having made a request that gets redirected - I'd like to auto follow but via a browser navigate to the new URL (i.e change the window.location to the new URL) instead of following via a new fetch request. Is this option possible? I don't need to have the new URL or the response actually surfaced to me from http client for this scenario.