cookie: cap expire times to 400 days #15937
Conversation
bagder
force-pushed
the
bagder/cookie-cap-again
branch
from
d6992f6 to
01a9dc2
Compare
|
@danielgustafsson I'm much more pleased with this approach as now we can still run all the cookie tests, including the capping of the expire times, without requiring debug builds. This version I believe we can merge. |
|
Analysis of PR #15937 at 343f740e: Test 61 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 2 different CI jobs (the link just goes to one of them). Test 483 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Test 1415 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 2 different CI jobs (the link just goes to one of them). Generated by Testclutch |
The pending cookie RFC update (currently known as 6265bis draft-19) says Let cookie-age-limit be the maximum age of the cookie (which name of Max-Age and an attribute-value of expiry-time. SHOULD be 400 days or less. This change makes received cookies over the wire get capped to 400 days. It does not cap the expiry date of cookies loaded from file. It does this by rounding the expire time to a even minute. This, to allow the test suite to do the same and have a chance to get the same number for stable testing without requiring a debug build. Closes #15937
bagder
force-pushed
the
bagder/cookie-cap-again
branch
from
343f740 to
5572c09
Compare
|
Clearly not good enough yet. It fails in CI intermittently. |
|
While not the cause of CI failures, we only align the expiration date on a 60 min boundary if the expiration is above the maxage, but in the test harness we always align for |
|
We actually don't need the test scripts to do it automatically as the content is delivered strictly as provided in the test* files. So we only use The remaining problem with this take is that if the test scripts generate the test file and aligns the max time to to ***60, there is still a small risk that when curl is invoked immediately afterwards, |
The test script now generates TWO numbers for each %days[], and the function that compares and verifies output is fine with either of the two numbers. This, so if the test case is generated the second before curl runs, that updated expiry number is also deemed okay. It still checks for an exact match of either number.
|
The test script now generates TWO numbers for each %days[], and the function that compares and verifies output is fine with either of the two numbers. This, so if the test case is generated the second before curl runs, that updated expiry number is also deemed okay. It still checks for an exact match of either number. |
|
This is a decent approach I think. We might be able to use this extended feature in the test suite for other things as well going forward. |
The pending cookie RFC update (currently known as 6265bis draft-19) says
This change makes received cookies over the wire get capped to 400 days.
It does not cap the expiry date of cookies loaded from file.
It does this by aligning the expire time to an even minute. This, to allow the test suite to do the same and have a chance to get the same number for stable testing without requiring a debug build.