A better way to manage cookies and session for HttpClient #77668
Comments
ziaulhasanhamim
added
the
api-suggestion
ghost
added
the
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackground and motivationIn HttpClient there is a behavior of one cookie container per HttpClientHandler instead of one per HttpClient. This behavior looks very weird and unnecessary to me. Because the HttpClientHandler is mostly cached. One CookieContainer per HttpClient is the intended behavior for almost all use cases. I don't think the current behavior is useful in any way and have no idea why .Net took this path with HttpClient. API ProposalThe best solution I can think of is to introduce a Session class(or even struct) that will manage the session for the requests made with it. public class Session : IDisposable
{
public CookieContainer CookieContainer { get; init; } = DefaultOne;
public bool UseCookies { get; init; } = true;
// more fields related to state management like Credentials, AllowAutoRedirect and all
public HttpRequestHeaders DefaultRequestHeaders { get; } = new HttpRequestHeaders();
public Uri BaseAddress { get; init; }
// same apis for send, get, post, put, delete, patch etc like HttpClient
}Sessions are very very useful. It helps to group certain requests. It would simplify the usage of HttpClient specially when using HttpClient as a singleton with a pooled connection. API UsageThe session will manage the cookies, headers, and all. var client = GetCachedClient();
using var session = new Session(client)
{
BaseAddress = ....
};
session.DefaultHeaders.Add(....);
var res1 = await session.PostAsync(path1, req);
var res2 = await session.GetAsync(path2);How nice is that. Alternative DesignsAn alternate way would be to add CookieContainers and all to the HttpClient itself. But Session objects are way easier to use and very simple RisksNo response
|
ManickaP
added
area-Extensions-HttpClientFactory
and removed
area-System.Net.Http
labels
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackground and motivationIn HttpClient there is a behavior of one cookie container per HttpClientHandler instead of one per HttpClient. This behavior looks very weird and unnecessary to me. Because the HttpClientHandler is mostly cached. One CookieContainer per HttpClient is the intended behavior for almost all use cases. I don't think the current behavior is useful in any way and have no idea why .Net took this path with HttpClient. API ProposalThe best solution I can think of is to introduce a Session class(or even struct) that will manage the session for the requests made with it. public class Session : IDisposable
{
public CookieContainer CookieContainer { get; init; } = DefaultOne;
public bool UseCookies { get; init; } = true;
// more fields related to state management like Credentials, AllowAutoRedirect and all
public HttpRequestHeaders DefaultRequestHeaders { get; } = new HttpRequestHeaders();
public Uri BaseAddress { get; init; }
// same apis for send, get, post, put, delete, patch etc like HttpClient
}Sessions are very very useful. It helps to group certain requests. It would simplify the usage of HttpClient specially when using HttpClient as a singleton with a pooled connection. API UsageThe session will manage the cookies, headers, and all. var client = GetCachedClient();
using var session = new Session(client)
{
BaseAddress = ....
};
session.DefaultHeaders.Add(....);
var res1 = await session.PostAsync(path1, req);
var res2 = await session.GetAsync(path2);How nice is that. Alternative DesignsAn alternate way would be to add CookieContainers and all to the HttpClient itself. But Session objects are way easier to use and very simple RisksNo response
|
CarnaViire
added
area-System.Net.Http
and removed
area-Extensions-HttpClientFactory
labels
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackground and motivationIn HttpClient there is a behavior of one cookie container per HttpClientHandler instead of one per HttpClient. This behavior looks very weird and unnecessary to me. Because the HttpClientHandler is mostly cached. One CookieContainer per HttpClient is the intended behavior for almost all use cases. I don't think the current behavior is useful in any way and have no idea why .Net took this path with HttpClient. API ProposalThe best solution I can think of is to introduce a Session class(or even struct) that will manage the session for the requests made with it. public class Session : IDisposable
{
public CookieContainer CookieContainer { get; init; } = DefaultOne;
public bool UseCookies { get; init; } = true;
// more fields related to state management like Credentials, AllowAutoRedirect and all
public HttpRequestHeaders DefaultRequestHeaders { get; } = new HttpRequestHeaders();
public Uri BaseAddress { get; init; }
// same apis for send, get, post, put, delete, patch etc like HttpClient
}Sessions are very very useful. It helps to group certain requests. It would simplify the usage of HttpClient specially when using HttpClient as a singleton with a pooled connection. API UsageThe session will manage the cookies, headers, and all. var client = GetCachedClient();
using var session = new Session(client)
{
BaseAddress = ....
};
session.DefaultHeaders.Add(....);
var res1 = await session.PostAsync(path1, req);
var res2 = await session.GetAsync(path2);How nice is that. Alternative DesignsAn alternate way would be to add CookieContainers and all to the HttpClient itself. But Session objects are way easier to use and very simple RisksNo response
|
|
Sharing some notes from @CarnaViire: We've discussed several asks for per-request/per-session things for
Main ask is Cookies, as currently Potential solution: add Downsides: APIs like Open questions:
Triage: we are aware this is a pain point for the users and want to solve this, but do it the right way, which is not as straight-forward as it might seem and needs careful design. For this, I'm moving it to future for now. We can always revisit and change the milestone. |
This will somehow solve the problem but this is also not that convenient Golang uses a cookie jar. This model is pretty similar to C# and not so helpful. As mentioned I have seen python solving this in the best way possible. They use session objects. Sessions are a way to group some requests based on common behavior regarding cookies, headers, and even middleware handlers. |
Background and motivation
In HttpClient there is a behavior of one cookie container per HttpClientHandler instead of one per HttpClient. This behavior looks very weird and unnecessary to me. Because the HttpClientHandler is mostly cached. One CookieContainer per HttpClient is the intended behavior for almost all use cases. I don't think the current behavior is useful in any way and have no idea why .Net took this path with HttpClient.
Although I'm not a big fan of HttpClientFactory but still when I'm using it handling cookies is complicated with it because of one cookie container per HttpClientHandler.
API Proposal
The best solution I can think of is to introduce a Session class(or even struct) that will manage the session for the requests made with it.
Sessions are very very useful. It helps to group certain requests. It would simplify the usage of HttpClient specially when using HttpClient as a singleton with a pooled connection.
API Usage
The session will manage the cookies, headers, and all.
How nice is that.
Alternative Designs
An alternate way would be to add CookieContainers and all to the HttpClient itself. But Session objects are way easier to use and very simple
Risks
No response
The text was updated successfully, but these errors were encountered: