hackney
hackney copied to clipboard
Cookie module issues
It seems that cookie parser in hackney_cookie uses 'Cookie' parser to parse 'Set-Cookie' header and 'Set-Cookie' builder to build 'Cookie' header. Also code seems to be outdated as it tries to parse comma as valid separator, that not the case in last RFC6265. As one particular problem that I'm run into is parser failing to proceed set-cookie with Expires attribute. If you try to request https://ya.ru it sets yandexuid cookie and removes S cookie (with Expires in past), but hackney:cookie silently ignores this:
> {ok, Status, Headers, Client} = hackney:request(get, "https://ya.ru", [], <<>>, []).
...
> Headers.
[{<<"Server">>,<<"nginx">>},
{<<"Date">>,<<"Fri, 12 Jun 2015 11:21:05 GMT">>},
{<<"Content-Type">>,<<"text/html; charset=UTF-8">>},
{<<"Content-Length">>,<<"9627">>},
{<<"Connection">>,<<"close">>},
{<<"Cache-Control">>,
<<"no-cache,no-store,max-age=0,must-revalidate">>},
{<<"Expires">>,<<"Fri, 12 Jun 2015 11:21:05 GMT">>},
{<<"Last-Modified">>,<<"Fri, 12 Jun 2015 11:21:05 GMT">>},
{<<"P3P">>,
<<"policyref=\"/w3c/p3p.xml\", CP=\"NON DSP ADM DEV PSD IVDo OUR IND STP PHY P"...>>},
{<<"Set-Cookie">>,
<<"S=; Expires=Tue, 14-Jun-2005 11:21:05 GMT; Path=/">>},
{<<"Set-Cookie">>,
<<"yandexuid=6091834691434108065; Expires=Mon, 09-Jun-2025 11:21:05"...>>},
{<<"X-Frame-Options">>,<<"DENY">>}]
> hackney:cookies(Headers).
[]
This particular problem addressed in PR #193. But I think cookie module need more attention to implement proper 'Set-Cookie' parser and 'Cookie' builder with respect to RFC6265. Another issue is that different cookies representations are used across project like {Name, Value}, {Name, [{Name,Value}|Attrs]}, {Name, Value, Attrs}. This adds complexity to lib usage and can be source of errors, maybe it make sense to go with some unified representation based on record or map.
Thanks for the ticket!
The respect for the accepted RFCs should certainly be improved. I will have a closer look on it sometimes this week.
About the API can you give me more details about what you expect from it? The reason to distinct the case
with our with attributes is that most of the time people don't put attributes. But the API can certainly be improved. About using maps I am not sure yet since it imply to only rely on Erlang 17 or 18 and remove support for old releases. Maybe it's the way to go though.
@mkurkov i merged #193 . I will take care 2.0.0 about improving the specification support and API improvements. Since 2.0 will be 18 only, maps could be used there.
@benoitc great! Regarding API, mostly I need silent cookie support - session should keep them, expire and use properly with respect to specs, manipulation of cookie store could be useful though. I think internally it can use records for cookie information, as it has well defined structure without need of dynamic maps features.