Web lists-archives.com

Re: [PATCH] t5551-http-fetch-smart.sh: sort cookies before comparing

Jeff King wrote:
> On Fri, Sep 07, 2018 at 07:22:05PM -0400, Todd Zullinger wrote:
>> With curl-7.61.1 cookies are sorted by creation-time¹.  Sort the output
>> used in the 'cookies stored in http.cookiefile when http.savecookies
>> set' test before comparing it to the expected cookies.
>> ¹ https://github.com/curl/curl/commit/e2ef8d6fa ("cookies: support
>>   creation-time attribute for cookies", 2018-08-28)
> According to that commit message, the creation-time sort is only for
> cookies of the same length. But it's not clear to me if that just means
> on-the-wire, and curl always stores by creation-time in the cookie file.

Yeah, I didn't dig into the curl code deeply to try and
understand it.  I did test with the only the curl package
downgraded to 7.61.0 to confirm the test worked without
sorting.  And I saw that the curl commit updated existing
tests to sort the test data.

> Either way, though, I guess it wouldn't matter for us as long as we
> choose some arbitrary re-ordering for what curl produces (i.e., the
> output of `sort`) and then make sure our "expect" output is in the same
> order. Which is basically what your patch does. One question, though:
>> diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
>> index 771f36f9ff..538656bfef 100755
>> --- a/t/t5551-http-fetch-smart.sh
>> +++ b/t/t5551-http-fetch-smart.sh
>> @@ -215,7 +215,7 @@ test_expect_success 'cookies stored in http.cookiefile when http.savecookies set
>>  	git config http.cookiefile cookies.txt &&
>>  	git config http.savecookies true &&
>>  	git ls-remote $HTTPD_URL/smart_cookies/repo.git master &&
>> -	tail -3 cookies.txt >cookies_tail.txt &&
>> +	tail -3 cookies.txt | sort >cookies_tail.txt &&
>>  	test_cmp expect_cookies.txt cookies_tail.txt
>>  '
> We pick the bottom 3 before sorting. How do we know those are the three
> we want to see?
> ...Ah, OK. The lines we are skipping are not actually cookies at all,
> but just header cruft. I wonder if:
>   grep "^[^#]" cookies.txt
> would be a better way of doing that, but that is certainly not something
> new.
> So this fix looks fine. It might be worth a comment above the creation
> of expect_cookies.txt to mention it must be in sorted order (of course
> anybody modifying it would see a test failure).

I thought about running the expect_cookies.txt file through
sort as well.  That would ensure that both files were using
the same sorting.  Whether that's needed on any platform
now, I don't know.  Maybe that would be a useful way to
protect against future edits to the expect_cookies.txt file
catching the editor?

I thought there might be a test function to sort the output,
but I was (incorrectly) thinking of check_access_log() which
Gábor added in e8b3b2e275 ("t/lib-httpd: avoid occasional
failures when checking access.log", 2018-07-12).

Perhaps it would be useful to have a test_cmp_sorted() to do
the simple dance of sorting the actual & expected.  I
haven't looked through the tests to see how often such a
function might be useful.

>> The in-development version of Fedora updated to the recently
>> released curl-7.61.1 in the past few days.  This isn't
>> breakage from the 2.19.0 cycle, but if the fix looks good to
>> everyone it would be nice to include it.  That way other
>> distributions and users who update git and curl to the most
>> recent releases won't run into this test failure.
>> I tested this against Fedora 30 (curl-7.61.1) as well as
>> previous releases from RHEL/CentOS 6/7 (7.19.7/7.29.0) and
>> Fedora 27/28/29 (7.55.1/7.59.0/7.61.0).
> You're pretty late in the 2.19 cycle, since the release is tentatively
> scheduled for Sunday. Though since this is just touching the test
> script, and since it looks Obviously Correct, I'm not opposed.

Yep, I knew the final was coming very soon.  I would not
have been surprised to see it land tonight while I was
finishing my testing of this patch. :)

I'm certainly covered for the Fedora packages.  It's hard to
say whether there are many other users/packagers who might
upgrade both git and curl and run into this.  So it may not
be worth even a small risk of making the change at this

On the other hand, the change only affects one test and may
be safe enough to apply.  I'll leave that choice in the
capable hands of our maintainer and the good folks here.

Thanks for a thoughtful review, as always.

That which seems the height of absurdity in one generation often
becomes the height of wisdom in the next.
    -- John Stuart Mill (1806-1873)