[RFC] Implement follow redirects

[alexeyzimarev]

The issue of redirect follow not working because of the missing cookies (#2045) triggered the following thought.

The default redirect follow by the message handler has these limitations:

• Cookie headers get populated to the consequent request only if the cookie container is used. When we removed the cookie container from the client in v109, this scenario stopped working (described in the issue referenced above)
• Redirect won't be followed when changing the scheme
• Max redirect count isn't supported in WASM
• Need to test if SeeOther redirect is supported, it might not be
• Need to test if headers are passed to the redirect

I did an experiment here #2058 to check feasibility, and it seems to be working fine. Everything described above can be implemented, some of the things need to be guarded with opt-in options (secure to insecure redirect support, forward auth header, maybe something else).

Any thoughts and suggestions welcome.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[repo-ranger]

⚠️ This issue has been marked wontfix and will be closed in 3 days

[kendallb]

Seems like a good idea to me.

[rassilon]

Based on my comments to #2045 , yes we definitely need to unbreak this. :( I really don't want to use selenium for some API tests when I can get away without using selenium if the cookies come back somewhere I can get my grubby hands on.

[rassilon]

Ok, I think i've got a handle on why the PR isn't working for me. i'll clean up a fork for you to take a look at. It was what was required for me to get past where I was stuck. (But i'll do that when after some shut-eye..)

[rassilon]

Okie, I created #2119 with my improvements. It got me past this scenario:

• request.CookeContainer supplied from caller
• request.Method == Post
• no json, just query string parameters

After the changes in #2119 the redirect is successfully made with a GET of the destination location due to a 302 being returned from my product.

As you can see, though, many questions remain in #2119 about what exactly to do in some of the scenarios that the HttpClient RedirectHandler class wants to do.

[alexeyzimarev]

Basically, what I planned to do:

• Add a redirect settings class, add a redirect settings to the client options and request options (override)
  • FollowRedirects (default the same as today)
  • FollowRedirectsToInsecure (false)
  • ForwardHeaders (true)
  • ForwardAuthorization (false)
  • ForwardCookies (true)
  • ForwardBody (true)
  • ForwardQuery (true)
  • MaxRedirects (don't know)
  • RedirectStatusCodes (what's in my PR)
• Disable redirects for HttpClient, obviously
• Extract a function to make the actual call
• Add a function to populate request data from previous request and redirect response
• Put it all in a loop

[rassilon]

Sounds good. We should probably add a ForwardFragment option (true) as well for completeness.
Any thoughts on whether we should expose to the client the ability to prevent the forced verb from post to get? (like Flurl does via the redirect event). Although it looks like Flurl does the force to get thing a little differently than the .net framework at present..

That's also a fun number of tests based on all of those settings. :)

[rassilon]

.net appears to force to get with a 300/301/302 when the verb is POST and 303 when the requested verb isn't GET or HEAD. While Flurl only does 301/302 at the moment when the verb is POST.