ASP.NET Core 8中TypedResults.File带ETag始终返回浏览器磁盘缓存问题

问题核心 #

使用TypedResults.File返回带ETag的PDF文件时，首次请求正常，但后续请求浏览器直接从磁盘缓存返回200，不会携带If-None-Match请求头到服务器，导致服务器端的304校验逻辑从未执行。

关键原因 #

浏览器的缓存策略由响应头Cache-Control决定，TypedResults.File不会自动配置验证类的缓存策略（比如no-cache）。如果没有显式设置，浏览器会采用默认的强缓存逻辑，直接使用本地缓存而不与服务器验证ETag。

下一步解决步骤 #

1. 配置Cache-Control头触发验证请求
   在返回文件响应前，添加Cache-Control头，强制浏览器每次请求都先到服务器验证ETag：

   // 在生成ETag和返回文件前设置
   HttpContext.Response.Headers.CacheControl = "no-cache";
   
   var etag = new EntityTagHeaderValue($"\"{invoicePdfVersion}-{lastModifiedOn.Ticks}\"");
   return TypedResults.File(
       pdfData,
       "application/pdf",
       "testing",
       false,
       lastModifiedOn,
       etag);
   

   • no-cache：允许浏览器缓存内容，但每次请求必须先向服务器验证ETag/Last-Modified，验证通过则返回304，否则返回新内容。
   • 也可使用must-revalidate，逻辑类似但缓存过期后必须强制验证。

2. 确保ETag生成与匹配逻辑准确

   • 检查ETag格式：EntityTagHeaderValue的ToString()会自动包含引号，生成时手动添加引号是正确的，也可以直接传入不带引号的字符串，构造函数会自动处理：

     var etag = new EntityTagHeaderValue($"{invoicePdfVersion}-{lastModifiedOn.Ticks}");
     

   • 匹配逻辑中，If-None-Match的值与ETag的字符串完全一致（包括引号）即可，你现有代码的匹配逻辑是正确的。

3. 验证响应头完整性
   首次请求时，确认响应头包含以下内容：

   • ETag：正确的带引号值
   • Cache-Control：已设置为no-cache或must-revalidate
   • Last-Modified：正确的文件修改时间
     只有这些头齐全，浏览器才会在后续请求中携带If-None-Match和If-Modified-Since头。

4. 清理缓存后测试
   测试前清空浏览器缓存或使用隐私模式，避免旧缓存干扰。正常刷新页面（F5）应触发带If-None-Match的请求，服务器端304逻辑会被执行。

补充说明 #

TypedResults.File不自动配置Cache-Control是因为缓存策略属于业务决策：部分场景（如静态资源）需要强缓存，而动态生成的内容（如你的PDF发票）需要每次验证。框架不会默认替开发者做这个选择，需手动配置。

内容的提问来源于stack exchange，提问作者Pure.Krome