From 9b9b63c2b9662906531b2cc763a0aab889d25b05 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 4 Nov 2026 20:19:21 +1100 Subject: [PATCH 1/3] Fix the weekday in the asctime Expires test freshness-expires-ansi-c sent "Thu Aug 8 02:01:18 2050", but 8 Aug 2050 is a Monday (the Thursday is 18 Aug, which the other Expires tests use). A cache that checks the day name against the date rejects the header, so the test reports a failure that has nothing to do with asctime parsing. Every other weekday-prefixed date in tests/ and test-engine/ matches its date; this was the only one that didn't. Co-Authored-By: Claude Sonnet 5.5 --- tests/expires-parse.mjs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/expires-parse.mjs b/tests/expires-parse.mjs index 1aaf556..852f4f4 100644 --- a/tests/expires-parse.mjs +++ b/tests/expires-parse.mjs @@ -71,7 +71,7 @@ export default requests: [ { response_headers: [ - ['Expires', 'Thu Aug 8 02:01:18 2050', false], + ['Expires', 'Mon Aug 8 02:01:18 2050', false], ['Date', 0] ], setup: true, From 86254f711beed862fe122e8e02d0979d8e591c37 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 4 Nov 2026 20:19:21 +1100 Subject: [PATCH 2/3] Add a check for an Expires whose weekday doesn't match its date Some caches validate the day name against the date and discard the header when they differ. The specification doesn't ask recipients to do that, so this is a check, not a conformance test: it records whether a cache still reuses a response with "Expires: Fri, 18 Aug 2050 02:01:18 GMT" (18 Aug 2050 is a Thursday). Co-Authored-By: Claude Sonnet 5.5 --- tests/expires-parse.mjs | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/tests/expires-parse.mjs b/tests/expires-parse.mjs index 852f4f4..cabd258 100644 --- a/tests/expires-parse.mjs +++ b/tests/expires-parse.mjs @@ -305,6 +305,25 @@ export default expected_type: 'not_cached' } ] + }, + { + name: 'Does HTTP cache reuse a response with a future `Expires` whose day-of-week does not match its date?', + id: 'freshness-expires-wrong-weekday', + depends_on: ['freshness-expires-future'], + kind: 'check', + requests: [ + { + response_headers: [ + ['Expires', 'Fri, 18 Aug 2050 02:01:18 GMT', false], + ['Date', 0] + ], + setup: true, + pause_after: true + }, + { + expected_type: 'cached' + } + ] } ] } From 0ce7f585c8b3a8bb2f7e9ce002104ab775c42455 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 4 Nov 2026 20:19:50 +1100 Subject: [PATCH 3/3] Correct the 32-bit and far-future Expires times Both values were 11 hours late, which looks like a timezone slip when they were computed. 2^31 seconds is Tue, 19 Jan 2038 03:14:08 GMT, not 14:14:08, so freshness-expires-32bit wasn't testing the 32-bit boundary. The far-future value is 9999999999 (the largest ten-digit timestamp), Sat, 20 Nov 2286 17:46:39 GMT, not Sun, 21 Nov 04:46:39. Weekdays updated to match. Co-Authored-By: Claude Sonnet 5.5 --- tests/expires-parse.mjs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/expires-parse.mjs b/tests/expires-parse.mjs index cabd258..7d62291 100644 --- a/tests/expires-parse.mjs +++ b/tests/expires-parse.mjs @@ -14,7 +14,7 @@ export default requests: [ { response_headers: [ - ['Expires', 'Tue, 19 Jan 2038 14:14:08 GMT', false], + ['Expires', 'Tue, 19 Jan 2038 03:14:08 GMT', false], ['Date', 0] ], setup: true, @@ -33,7 +33,7 @@ export default requests: [ { response_headers: [ - ['Expires', 'Sun, 21 Nov 2286 04:46:39 GMT', false], + ['Expires', 'Sat, 20 Nov 2286 17:46:39 GMT', false], ['Date', 0] ], setup: true,