http: ignore invalid Retry-After dates

[jay]

• If the Retry-After date is in the past then set the retry after time to 0 instead of a negative number.

Prior to this change, libcurl could set the retry after time to a negative number of seconds. That is not documented and may be unexpected by the user.

Closes #xxxx

[jay]

This change is causing test 1596 to fail. The test is for Retry-After timestamp parsing using a date in the past, so it expects CURLINFO_RETRY_AFTER to return a negative number.

curl/tests/data/test1596

Lines 15 to 18 in fb1883d

	HTTP/1.1 429 Too Many Requests
	Date: Thu, 11 Jul 2019 02:26:59 GMT
	Server: test-server/swsclose
	Retry-After: Thu, 11 Jul 2024 02:26:59 GMT

curl/tests/libtest/lib1594.c

Lines 52 to 58 in fb1883d

	#ifdef LIB1596
	/* we get a relative number of seconds, so add the number of seconds
	we're at to make it a somewhat stable number. Then remove accuracy. */
	retry += time(NULL);
	retry /= 10000;
	#endif
	printf("Retry-After %" CURL_FORMAT_CURL_OFF_T "\n", retry);

If there's no objection I will change the timestamp to something in the future.

[bagder]

Nice catch!

[testclutch]

Analysis of PR #15833 at 75b506f6:

Test 1596 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 94 different CI jobs (the link just goes to one of them).

Generated by Testclutch

[jay]

Being able to set the retry-after date this far into the future (year 2036) also makes me wonder. Is there an upper limit on what an acceptable time should be? I didn't see one in the RFC but I would think after some number of hours it's long enough

[bagder]

I would think after some number of hours it's long enough

Agreed. Maybe cap it at 5 or 10 hours or so?

[jay]

I really don't know. I changed the max to 24 hours but did not document it so that we'll have some flexibility to change it in the future.

[jay]

I changed my mind and made it 6 hours. 6 hours seems like a long time. Would a server return a longer time?

[bagder]

Highly unlikely. And even if there is a single one out there doing this, I don't think trying a little too early every 6 hours can be considered abuse.

[dfandrich]

I could see a legitimate use case in a server using a longer time, like a day (or even more), to get clients to retry after a scheduled maintenance.

[jay]

Ok. I agree that there may be legit use cases and also that it's acceptable to try again in a shorter period of time so I landed it unchanged with a 6 hour limit.