Repository navigation
[RFC] Implement follow redirects #2059
Description
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
SeeOtherredirect 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.
Activity
stale commentedon May 22, 2023
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 commentedon May 22, 2023
kendallb commentedon Jul 13, 2023
Seems like a good idea to me.
rassilon commentedon Jul 19, 2023
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 commentedon Jul 25, 2023
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 commentedon Jul 25, 2023
Okie, I created #2119 with my improvements. It got me past this scenario:
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 commentedon Aug 20, 2023
Basically, what I planned to do:
rassilon commentedon Aug 20, 2023
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 commentedon Aug 20, 2023
.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.
Implement custom redirect handling to fix lost Set-Cookie on redirects
Implement custom redirect handling to fix lost Set-Cookie on redirects (
alexeyzimarev commentedon Jun 2, 2026
Implemented in #2360 (commit ae6b354) — somehow the issue wasn't auto-closed at merge.
Everything from the original plan landed:
RedirectOptionsclass withFollowRedirects,FollowRedirectsToInsecure,ForwardHeaders,ForwardAuthorization(+ForwardAuthorizationToExternalHost),ForwardCookies,ForwardBody,ForwardQuery,MaxRedirects, andRedirectStatusCodes(301/302/303/307/308).HttpClient.AllowAutoRedirect = falseso RestSharp owns the redirect loop.SendWithRedirectsAsyncinRestClient.Async.csthat parsesSet-Cookieat every hop — fixing the original cookie-loss-on-redirect problem from FollowRedirects not working #2045 / Duplicate cookies #2077.RedirectTests.csandCookieRedirectTests.cs.The only suggestion from this thread that didn't ship was
ForwardFragment— URL fragments aren't sent over HTTP, so the option would be a no-op.Closing as completed. Thanks @rassilon and @kendallb for the design input on the original thread.