docmirror/dev-sidecar · warning
cache intercept: 解析 if-modified-since 失败:
Error message
cache intercept: 解析 if-modified-since 失败:
What it means
The cache interceptor reads the request's `if-modified-since` header to compare against a cached resource's Last-Modified. If the header value can be parsed neither as a number (epoch) nor as a date string, it logs this warning and returns null, so conditional-request handling is skipped and the response is treated without cache revalidation.
Source
Thrown at packages/mitmproxy/src/lib/interceptor/impl/req/cacheRequest.js:53
}
// 获取 lastModifiedTime 的方法
function getLastModifiedTimeFromIfModifiedSince (rOptions, log) {
// 获取 If-Modified-Since 用于判断是否命中缓存
const lastModified = rOptions.headers['if-modified-since']
if (lastModified == null || lastModified.length === 0) {
return null // 没有lastModified,返回null
}
// 优先尝试作为纯数字时间戳(毫秒)解析,避免 new Date() 将其当作无效日期而返回 NaN
if (PURE_NUMBER_RE.test(lastModified)) {
return Number.parseInt(lastModified, 10)
}
// 再尝试作为日期字符串解析
const time = new Date(lastModified).getTime()
if (Number.isNaN(time)) {
log.warn(`cache intercept: 解析 if-modified-since 失败: '${lastModified}'`)
return null
}
return time
}
module.exports = {
name: 'cacheRequest',
priority: 104,
requestIntercept (context, interceptOpt, req, res, ssl, next) {
const { rOptions, log } = context
if (rOptions.method !== 'GET') {
return // 非GET请求,不拦截
}
// 获取 Cache-Control 用于判断是否禁用缓存
const cacheControl = rOptions.headers['cache-control']View on GitHub (pinned to 7710cd56cc)
Solutions
- Fix the client to send a proper RFC 7232 date (e.g. 'Wed, 21 Oct 2015 07:28:00 GMT') or an epoch number.
- Remove the `if-modified-since` header if the client cannot produce a valid value — a plain GET will still work, just uncached.
- If you control a proxying layer, normalize or strip malformed If-Modified-Since headers before they reach dev-sidecar.
Example fix
// before headers['If-Modified-Since'] = new Date().toLocaleString() // after headers['If-Modified-Since'] = new Date().toUTCString()
Defensive patterns
Strategy: validation
Validate before calling
function isValidIfModifiedSince(v) {
if (v == null) return false
if (!Number.isNaN(Number.parseInt(v, 10))) return true
return !Number.isNaN(new Date(v).getTime())
}
// call before sending the header Type guard
const isHttpDate = (v) => typeof v === 'string' && /^([A-Za-z]{3},\s\d{2}\s[A-Za-z]{3}\s\d{4}\s\d{2}:\d{2}:\d{2}\sGMT|\d+)$/.test(v) Prevention
- Always send If-Modified-Since via new Date(x).toUTCString()
- Strip unknown cache headers from hand-built HTTP clients
- Add a unit test that round-trips your header value through Date parsing
When it happens
Trigger: An HTTP client sends an `If-Modified-Since` header with a malformed value (non-numeric, non-HTTP-date, e.g. 'unknown', '0', partial timestamp) and the request goes through the cache interceptor.
Common situations: Custom scripts/HTTP clients hand-crafting the header; proxies upstream corrupting header values; tests sending placeholder values; locale-formatted dates not conforming to RFC 7232 IMF-fixdate.
Related errors
AI-assisted analysis of docmirror/dev-sidecar@7710cd56cc (2026-08-31).
Data as JSON: /api/errors/ed01908dc02daa9c.
Report an issue: GitHub.