RFC6265 compliant date parsing.

[mekras]

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
License	MIT

What's in this PR?

Implementation of a cookie-date parsing algorithm described in RFC6265 section 5.1.1. Ported from here: https://github.com/salesforce/tough-cookie/blob/master/lib/cookie.js

Why?

Using only DateTime::COOKIE format is not compliant with this RFC6265. For example valid date "Tuesday, 31 Mar 99 07:42:12 GMT" will cause an exception.

Checklist

• Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix

To Do

• More tests to validate parsing (I'm not familiar with phpspec enough to do it myself).

[sagikazarmark]

This is awesome @mekras, thank you.

[dbu]

is the cookie date format different from other date format specifications? i am unhappy about adding such a parser because of future maintainance - but if its a cookie specific thing, it does belong here.

we could make the date parser its own static public method in a separate class. then it would also be easier to test all kind of edge cases. we should test it quite a bit to avoid it working worse in the end than php DateTime.

[sagikazarmark]

Hm, separating logic makes sense.

[joelwurtz]

Hm, separating logic makes sense.

👍 And this could go in php-http/message as it's agnostic from HttpClient, then this plugin could use the parser.

[sagikazarmark]

Oh yes, I totally missed this is not in message

[mekras]

is the cookie date format different from other date format specifications?

Yes, it's different. AFAIK other HTTP dates uses RFC5322 date/time format which is only a subset of format defined in RFC6262.

[dbu]

urks. whyever they needed to do that. but if thats the case we should support it. @sagikazarmark do you think we still should split the parser out of the cookie plugin? i'd say it should...

[sagikazarmark]

Definitely, the plugin itself should contain as little logic as possible.

[sagikazarmark]

Ping @mekras

[mekras]

I'm here. How can I help?

[sagikazarmark]

As discussed above, this parsing logic may better fit into the message package where we have other cookie related stuff as well. Would be nice if you could separate it: main logic->message and only use the parser here.

I guess there is not much sense in abstracting this logic, so I could even imagine a static class doing this stuff. CookieUtil or something like that?

WDYT?

[mekras]

I have been convinced many times that my vision of architecture is at variance with yours. So make your own decision. Just tell me what to do with this code, and I'll do it.

[aaa2000]

@mekras Can you create the PR on https://github.com/php-http/message ?