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.

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

Seems like a good idea to me.

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.

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..)

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.

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

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. :)

.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.