fix(handleCacheHeaders): round modifiedTime to seconds#1262
Conversation
…eHeaders Truncate milliseconds from modifiedTime before comparing with If-Modified-Since header. HTTP dates have second precision, so a modifiedTime with milliseconds (e.g., 12:00:00.123) would never match the client's rounded If-Modified-Since header (12:00:00.000), causing unnecessary 200 responses instead of 304. Closes h3js#1261
📝 WalkthroughWalkthroughThe implementation truncates milliseconds from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
test/utils.test.ts (1)
380-393: Good test coverage for the millisecond precision bug.The test correctly validates that a modifiedTime with milliseconds (00:00:00.500Z) matches an If-Modified-Since header without milliseconds, returning a 304 status as expected.
Optional enhancement: Consider also asserting that the Last-Modified response header is formatted without milliseconds:
expect(res.status).toBe(304); + expect(res.headers.get("last-modified")).toBe("Fri, 01 Jan 2021 00:00:00 GMT");This would provide more comprehensive validation that the header format is correct, not just that the comparison logic works.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/utils/cache.ts(1 hunks)test/utils.test.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
test/utils.test.ts (3)
src/utils/cache.ts (1)
handleCacheHeaders(15-52)src/index.ts (1)
handleCacheHeaders(172-172)src/event.ts (1)
res(77-79)
🔇 Additional comments (1)
src/utils/cache.ts (1)
26-34: LGTM! Clean fix for millisecond precision issue.The placement of
setMilliseconds(0)is correct—it truncates milliseconds immediately after constructing the Date object and before both setting the Last-Modified header and performing the If-Modified-Since comparison. This ensures HTTP-date format compliance (second precision per RFC 7231) and fixes the cache validation mismatch described in issue #1261.
modifiedTime to seconds
Summary
This PR fixes issue #1261 where
handleCacheHeaderscomparesmodifiedTimewith millisecond precision, causing cache validation to always fail when the source date has non-zero milliseconds.The Problem
modifiedTimeretains millisecond precision (e.g.,2025-01-01T12:00:00.123Z)Last-Modifiedheader is formatted without milliseconds per HTTP spec (e.g.,Wed, 01 Jan 2025 12:00:00 GMT)If-Modified-Sincewith the truncated timestamp1735732800000 >= 1735732800123isfalseThis causes unnecessary 200 responses instead of 304, wasting bandwidth and server resources.
The Fix
Truncate milliseconds from
modifiedTimebefore both setting the header and making the comparison:Test
Added a test case that specifically uses a date with milliseconds to verify the fix works correctly.
Test Plan
pnpm testpassesCloses #1261
Summary by CodeRabbit
Bug Fixes
Tests
✏️ Tip: You can customize this high-level summary in your review settings.