-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support persisting cookies from multiple domains #314
Conversation
8ed83f9
to
f5a8833
Compare
48e1b62
to
d3b0ae7
Compare
f5a8833
to
e4a84bc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't done a functional test yet but the code looks good!
This was a breaking change introduced in time v0.3.0
220b326
to
08ad9c0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For https://www.youtube.com
, HTTPie stores the cookies under the domain .youtube.com
rather than youtube.com
. (Cookies for https://www.wikipedia.org
do end up under wikipedia.org
.)
I haven't read the spec but I assume these have different meanings that we need to keep?
(Reusing an xh session file in HTTPie causes one of the three YouTube cookies to be stored twice, once with the dot and once without. Then HTTPie will also send it twice, but xh only once.)
Co-authored-by: Jan Verbeek <[email protected]>
The cookie crate is where the leading dot is removed from the domain. See rwf2/cookie-rs#73 I was initially tempted to declare it as an HTTPie bug, but the behaviour is consistent with Requests' cookie jar
|
Hmmm. Both Firefox and Chromium seem to remember (in the dev tools and in the cookies sqlite db) whether there was a leading dot, even if they presumably ignore it in the end. Is there an easy way for us to remember it too? |
I can't think of a way that doesn't involve forking cookie-rs and cookie-store. A somewhat random question; do you go with git-rebase or git-merge when bringing changes back from master to a feature branch? |
Yeah, I don't see a way either. Let's leave this as it is. I think it'd be good to document this divergence from HTTPie somewhere, though it's too obscure to go in the README. ("Formatted output is always UTF-8" also doesn't really belong there I think, it needs a longer explanation to clarify what it even means.) Maybe a separate markdown file?
I usually don't rebase if I already made a PR or if I touched code/logic that changed in master. Otherwise things can get messy. |
Shall we track it as an issue for now? I have now documented couple of existing differences in #322 |
This can be useful when reusing anonymous sessions for multiple domains or when cookies are set as users are redirected from one domain to another.
Before:
After:
Resolves #244