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

  1. Fix the client to send a proper RFC 7232 date (e.g. 'Wed, 21 Oct 2015 07:28:00 GMT') or an epoch number.
  2. Remove the `if-modified-since` header if the client cannot produce a valid value — a plain GET will still work, just uncached.
  3. 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

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.