Skip to content

fix core: storing all cookies without possibly wrong selection, keeping session cookies semantics#1292

Open
alex-aparin wants to merge 13 commits into
userver-framework:developfrom
alex-aparin:cookies_fix
Open

fix core: storing all cookies without possibly wrong selection, keeping session cookies semantics#1292
alex-aparin wants to merge 13 commits into
userver-framework:developfrom
alex-aparin:cookies_fix

Conversation

@alex-aparin

Copy link
Copy Markdown
Contributor

As mentioned previously in issue #1182. The current implementation of cookie storage in clients::http::response does not conform to RFC 6265 (it can incorrectly write cookies). Additionally, the accessor methods for Max-Age/Expires have default values, which is also incorrect (breaking the semantics for Session Cookies). The goal of this PR is primarily to fix the incorrect cookie writing, but without a full-fledged implementation of CookiesJar.


Note: by creating a PR or an issue you automatically agree to the CLA. See CONTRIBUTING.md. Feel free to remove this note, the agreement holds.

@alex-aparin

alex-aparin commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

UPD: I have noticed some updates in master branch like this. Please note that just overwriting cookie with the same name is not enough, you should take into account expire/max age and domains/urls, because in some cases we should delete cookie at all or just keep additional cookie with the same name but for another domain/url. That's why I am just recording all cookies without any actions (without implementing full cookiejar)

@Malevrovich

Copy link
Copy Markdown
Contributor

Hi, and thanks for the PR!

I’m not fully comfortable with the idea of putting all cookies into a vector. At the very least, this changes the public API, and I’m pretty sure many users rely on the current way cookies are exposed and read.

Would you be interested in properly supporting the cases that don’t fully comply with the RFC instead? I’d be happy to review such a change and help get it merged.

I’d prefer to avoid moving everyone from a map to a vector now, only to potentially move them back to a map later.

@alex-aparin
alex-aparin marked this pull request as draft July 16, 2026 09:33
@alex-aparin

alex-aparin commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Hi all. Thank you for response. There was hot discussion in userver's telegram group about breaking changes, I'll make this pr as draft, additional tests for tricky cookies will be added. I think the better way is to add additional method to allow user to specify - use old but wrong api with the same semantics (map of cookies) or use new method which will return CookieJar with needed getters (some kind of map of map (or map of list) can be used internally)

@alex-aparin
alex-aparin marked this pull request as ready for review July 20, 2026 20:55
@alex-aparin

alex-aparin commented Jul 20, 2026

Copy link
Copy Markdown
Contributor Author

This version can be viewed as starting point for API and tests for CookieJar compliable with RFC 6265.
Resume of commits:

  1. Reverted changes. New api is compatible with current one
  2. Implemented CookieJar, it now primarly used for receiving cookies from server. It has also simple api (but not so effective in terms of parsing urls) in order to SEND cookies, we need to think about API to set this to http client.
  3. Added tests to covert tricky cookies.

This was not so easy as I thought and a little bit messy from my implementation, but I hope storage covers many issues, any help will be greatly appreciated. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants