You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After having reviewed http-rs/tide#380, I'm now wondering if we should have a different approach for cookies than what we currently have. This supersedes #48.
Current API
We currently provide APIs for both getting and setting cookies in the request and response headers. Each call to e.g. Response::cookie decodes the full set of cookies, and returns the corresponding cookie:
This has the downside of being rather slow, as each access of a cookie ends up going through a full decode stage.
Proposed API
In http-rs/tide#380Request has cookie,set_cookie, and remove_cookie methods that only parse cookies once. And even better: it automatically sets the correct Set-Cookie headers on the Response by calculating the delta of the cookies that have been set before, and which need to be set again.
To make that API easier to write, I'd like to propose we change the current cookies API in http-types to primarily operate on CookieJar instead.
implRequest{/// Parse the cookies from the headers into a `CookieJar`pubfncookies(&self) -> CookieJar;/// Encodes the delta of the cookies in the `CookieJar` as the corresponding HTTP headers.pubfnset_cookies(&mutself,jar:&CookieJar);}implResponse{/// Parse the cookies from the headers into a `CookieJar`pubfncookies(&self) -> CookieJar;/// Encodes the delta of the cookies in the `CookieJar` as the corresponding HTTP headers.pubfnset_cookies(&mutself,jar:&CookieJar);}
This way http-types can operate on cookie jars, rather than on individual cookies. And as we can see in Tide it would then be possible to at the framework layer enable operating on individual cookies instead.
After having reviewed http-rs/tide#380, I'm now wondering if we should have a different approach for cookies than what we currently have. This supersedes #48.
Current API
We currently provide APIs for both getting and setting cookies in the request and response headers. Each call to e.g.
Response::cookie
decodes the full set of cookies, and returns the corresponding cookie:https://github.com/yoshuawuyts/http-types/blob/b1623854102986b151d07406b6949d985787d1fd/src/response.rs#L305-L314
https://github.com/yoshuawuyts/http-types/blob/b1623854102986b151d07406b6949d985787d1fd/src/response.rs#L331-L335
This has the downside of being rather slow, as each access of a cookie ends up going through a full decode stage.
Proposed API
In http-rs/tide#380
Request
hascookie
,set_cookie
, andremove_cookie
methods that only parse cookies once. And even better: it automatically sets the correctSet-Cookie
headers on theResponse
by calculating the delta of the cookies that have been set before, and which need to be set again.To make that API easier to write, I'd like to propose we change the current cookies API in
http-types
to primarily operate onCookieJar
instead.This way
http-types
can operate on cookie jars, rather than on individual cookies. And as we can see in Tide it would then be possible to at the framework layer enable operating on individual cookies instead.cc/ @tirr-c @rylev
The text was updated successfully, but these errors were encountered: