On Sunday 13 March 2016 16:15:38 Daniel Stenberg wrote:
> On Sun, 13 Mar 2016, Tim Rühsen wrote:
> > How do you judge the expected against what the browsers accept ? In the
> > means of "strict when generating, relaxed with parsing".
>
> In general for protocols, the "liberal in what you accept" idea has proved
> itself to be a really bad idea many times over by now. But cookies come from
> a different age and they're produced by so many different implemenatations
> (there's really no major 3-4 ipmlementations there but rather hundreds or
> thousands of custom ones) that fixing the generators is next to impossible.
> That's also a reason why moving away from cookies to something else is so
> extremely hard.
>
> Anyway, that's why we're stuck with being liberal enough in the parsing to
> accept most of the world's weirdo cookie headers.
>
> > At least the browsers are well-used real implementations...
>
> Yes. That's also why I believe that for some of those test case failures
> where we can see that the browsers don't adhere to the spec or even between
> other browsers it is *probably* mostly for cookie formats that are
> extremely rare in the wild so it doesn't really matter what the browsers do
> in those cases.
>
> Browsers in general try to keep or raise the number of users and they do
> that (among other ways) by making sure the browsers work with the sites the
> users visit. If browser A breaks on a popular site, users will switch to
> browser B. Over time, that makes most browsers support 99.X% of all sites
> their users go to and the few remaining sites that use something the
> browsers don't support have a low enough user share to not warrant the
> effort to support that too. (Well, yes, in many cases fixing could mean
> pursuading the sites to fix their broken data/code but that's besides the
> point here.)
>
> So, if wget2/curl would fail some of those tests where the browsers also are
> failing, that would not necessarily mean that we should fix the code, maybe
> we should fix the spec/test instead. And failing such a test would be less
> of a concern to me than failing a test that all the browsers agree with
> already.

I basically agree with you in those points.

Just an intermediate report...
Today I implemented a unit test for those test cases using libwget (will come
with wget2). In the first run just 136 out of 222 tests made it.

The algorithm is (for each *-test file)
- create a HTTP response from the *-test file and parse it
- sanitize the cookies
- store the cookies into a cookie database
- construct a Cookie: header from the cookie database (using home.example.org
as domain)
- compare the result with *-expected

0028-expected is broken / contains bullshit - I opened an issue at Github.

The unit test approach likely won't work for curl, though...

Regards, Tim

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html