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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
