New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
【Q111】http 响应头中的 ETag 值是如何生成的 #112
Comments
关于
以上几个条件是理论上的成立条件,那在真正实践中,应该如何处理? 我们来看一下 nginx 中 ETag 的生成我翻阅了 etag = header.last_modified + header.content_lenth 可见源码位置,并在以下贴出: ngx_http_core_modules.c etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
r->headers_out.last_modified_time,
r->headers_out.content_length_n)
- etag->value.data; 总结: 随手在我的k8s集群里找个 $ curl --head 10.97.109.49
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Tue, 10 Dec 2019 06:45:24 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Apr 2019 10:18:21 GMT
Connection: keep-alive
ETag: "5cbee66d-264"
Accept-Ranges: bytes 由 > new Date(parseInt('5cbee66d', 16) * 1000).toJSON()
"2019-04-23T10:18:21.000Z"
> parseInt('264', 16)
612 Nginx 中的 ETag 算法及其不足协商缓存用来计算资源是否返回 304,我们知道协商缓存有两种方式
既然在
那下一个问题:如果 http 响应头中 ETag 值改变了,是否意味着文件内容一定已经更改 答案:不能。 因此使用 nginx 计算 304 有一定局限性:在 1s 内修改了文件并且保持文件大小不变。但这种情况出现的概率极低就是了,因此在正常情况下可以容忍一个不太完美但是高效的算法。 相关问题 |
Last-Modified 变了,但是Content-Length没变(文件内容不变),是否意味着etag的缓存失效 |
@jacintoface 也可以这么理解 |
No description provided.
The text was updated successfully, but these errors were encountered: