dlang-requests
dlang-requests copied to clipboard
Wrong cookie handling
If the domain value of a cookie does not start with a . it will be added by the client. A cookie will be overwritten (or deleted) by a subsequent cookie exactly matching the name, path and domain of the original cookie.
How do browser cookie domains work? How to handle multiple cookies with the same name?
Hello @Domain,
Thanks for report, will look a bit later.
Hello @Domain
set-cookie processed in https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L631 and as far as I can see it breaks https://tools.ietf.org/html/rfc6265#section-5.2.3 in that it do not strip leading dot away.
5.2.3. The Domain Attribute
If the attribute-name case-insensitively matches the string "Domain",
the user agent MUST process the cookie-av as follows.
If the attribute-value is empty, the behavior is undefined. However,
the user agent SHOULD ignore the cookie-av entirely.
If the first character of the attribute-value string is %x2E ("."):
Let cookie-domain be the attribute-value without the leading %x2E
(".") character.
Otherwise:
Let cookie-domain be the entire attribute-value.
Convert the cookie-domain to lower case.
Append an attribute to the cookie-attribute-list with an attribute-
name of Domain and an attribute-value of cookie-domain.
Then, when we build headers for next request https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L493 I just follows rules from RFC.
Can you, please, give me example of wrong request processing, so that I can find where exactly problem is.
Thanks
@ikod According to https://tools.ietf.org/html/rfc6265#section-5.1.3
5.1.3. Domain Matching A string domain-matches a given domain string if at least one of the following conditions hold: o The domain string and the string are identical. (Note that both the domain string and the string will have been canonicalized to lower case at this point.) o All of the following conditions hold: * The domain string is a suffix of the string. * The last character of the string that is not included in the domain string is a %x2E (".") character. * The string is a host name (i.e., not an IP address).
So "x.example.com" matches "example.com" Your implementation is followed RFC2965, not RFC6265 https://github.com/ikod/dlang-requests/blob/master/source/requests/utils.d#L113
See also: https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains/
A cookie will be overwritten (or deleted) by a subsequent cookie exactly matching the name, path and domain of the original cookie. https://tools.ietf.org/html/rfc6265#section-5.3
11. If the cookie store contains a cookie with the same name, domain, and path as the newly created cookie: 1. Let old-cookie be the existing cookie with the same name, domain, and path as the newly created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) 2. If the newly created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is set, abort these steps and ignore the newly created cookie entirely. 3. Update the creation-time of the newly created cookie to match the creation-time of the old-cookie. 4. Remove the old-cookie from the cookie store. 12. Insert the newly created cookie into the cookie store.
Now the new cookie is just appended to the end. https://github.com/ikod/dlang-requests/blob/master/source/requests/http.d#L631
@Domain I see, this should be fixed. It will take some time.