防止不必要的“If-Modified-Since” Amazon S3 上的请求和 304 响应

发布于 2025-01-07 02:09:00 字数 1410 浏览 2 评论 0原文

我正在使用适用于 .NET 的 AWS 开发工具包上传多个图像。在发出 PutObjectRequest 之前，我分别为未来的时间间隔和日期设置了 max-age 和 expires 标头。

这是初始图像请求：

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:assets.mywebsite.com.s3-us-west-1.amazonaws.com
If-Modified-Since:Sun, 19 Feb 2012 18:36:48 GMT
If-None-Match:"f19920f9367b698451d6c964d3ae714a"
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11

这是 S3 响应。它发送回正确的缓存标头：

Accept-Ranges:bytes
Cache-Control:public, max-age=31536000
Content-Length:9180
Content-Type:image/jpeg
Date:Sun, 19 Feb 2012 19:16:18 GMT
ETag:"f19920f9367b698451d6c964d3ae714a"
Expires:Sat, 19 Feb 2022 18:36:48 GMT
Last-Modified:Sun, 19 Feb 2012 18:36:48 GMT
Server:AmazonS3

但是，每个后续请求仍然会导致 304（而不是来自缓存的 200）：

Status Code:304 Not Modified

注意，我没有按 F5。

我读过，当您混合使用 ETag 和 Expires/Cache-Control 时，ETag 通常会用于每个请求并完全忽略缓存。我还了解到无法在 S3 中禁用 ETag。

我只是想提高速度并降低成本。在我放弃之前，我想我应该问问 SO 社区。

关于如何防止 304 有什么想法吗？

更新：

就缓存而言，浏览器似乎变得越来越复杂。正如 marcind 指出的那样，这是客户端浏览器问题。经过在其他浏览器和不同场景中的测试（即直接在chrome中加载图像（请求图像url）与简单地在存在网页的情况下查看图像具有不同的效果）

原文

I'm using AWS SDK for .NET to upload several images. Before making the PutObjectRequest, I set the max-age and expires headers for far future intervals and dates, respectively.

This is the initial image request:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:assets.mywebsite.com.s3-us-west-1.amazonaws.com
If-Modified-Since:Sun, 19 Feb 2012 18:36:48 GMT
If-None-Match:"f19920f9367b698451d6c964d3ae714a"
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11

Here is the S3 response. It sends back the correct caching headers:

Accept-Ranges:bytes
Cache-Control:public, max-age=31536000
Content-Length:9180
Content-Type:image/jpeg
Date:Sun, 19 Feb 2012 19:16:18 GMT
ETag:"f19920f9367b698451d6c964d3ae714a"
Expires:Sat, 19 Feb 2022 18:36:48 GMT
Last-Modified:Sun, 19 Feb 2012 18:36:48 GMT
Server:AmazonS3

However, every subsequent request still results in a 304 (not a 200 from cache):

Status Code:304 Not Modified

Note, I'm not hitting F5.

I've read that when you mix ETags and Expires/Cache-Control, ETags will generally be used for each request and ignore caching altogether. I've also read that there is no way to disable ETags in S3.

I'm simply trying to increase speed and decrease costs. Before I give up I figured I'd ask the SO community.

Any Ideas on how to prevent the 304's?

UPDATE:

It would appear browsers are becoming more and more sophisticated as far as caching goes. As marcind points out, it's a client browser issue. After testing in other browsers and different scenarios (ie, loading the image directly in chrome (requesting the image url) as opposed to simply viewing the image in the presence of a web page has different effects)

分享到QQ

分享到微博