Cloudflare不遵守vary cache hit,导致了文件内容错误的缓存文件输出

cloudflare不遵守vary cache hit,导致了文件内容错误的缓存文件输出


我有文件需要vary根据accept和accept-encoding输出不同的数据,但是经过cloudflare后,他只会输出一份相同的文件信息

translate
Cloudflare does not obey vary cache hit, resulting in cache file output with wrong file content


I have a file that needs vary to output different data based on accept and accept-encoding, but after cloudflare, he will only output a copy of the same file information

Others have posted the same:

https://community.cloudflare.com/search?q=vary%20cdn

cloudflare 他需要多长时间来修复这个问题?
我需要使用根据 Origin请求头动态计算出的Access-Control-Allow-Origin,一定要始终加上Vary: Origin,以便返回不同的CORS 场景
Vary问题出现在可缓存的静态资源。
如果是为动态接口设置 CORS,反正都不允许缓存,当然也就没这个问题了。

Fetch 规范中专门讲了Vary: Origin在 CORS 响应中该如何使用 https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches ,其中第一段是:

If CORS protocol requirements are more complicated than setting Access-Control-Allow-Origin to * or a static origin, Vary is to be used.
翻译一下就是“如果你的 Access-Control-Allow-Origin响应头不是简单的写死成了*或者某一个特定的源(就是我总结的条件型 CORS 响应),那么你就应该加上Vary: Origin响应头。

In particular, consider what happens if Vary is not used and a server is configured to send Access-Control-Allow-Origin for a certain resource only in response to a CORS request. When a user agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lack Access-Control-Allow-Origin and the user agent will cache that response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, without Access-Control-Allow-Origin.
这第二段是特别指出“区分对待有无 Origin 请求头”的同时不加Vary:Origin头会引起缓存错乱问题。

vary问题在nginx,kangle web server中都不存在这些问题现象。只有cloudflare 出现了异常

translate
Cloudflare how long does he need to fix this problem?
I need to use Access-Control-Allow-Origin, which is calculated dynamically according to the Origin request header. I must always add Vary: Origin, and the brake returns to different CORS scenarios.
Vary problems occur with static resources that can be cached.
If CORS is set for the dynamic interface, the cache is interrupted anyway, and of course there is no such problem.

The extraction specification specifically talked about how Origin should use https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches in the CORS response, where the first paragraph is:

If the CORS protocol requirements are more complicated than setting “Access-Control-Allow-Origin” to * or a static source, then “Vary” should be used.
The translation is "If your Access-Control-Allow-Origin response header is not simply written into * or someone specific source (that is, the condition type CORS response I summarized), then you should add the response header.

In particular, consider what happens if “Vary” is not used and the server is configured to only send “Access-Control-Allow-Origin” for specific resources in response to CORS requests. When the user agent receives a response to a non-CORS request for the resource (for example, as a result of a navigation request), the response will lack “Access-Control-Allow-Origin” and the user agent will cache the response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use the cached response from the previous non-CORS request without the “Access-Control-Allow-Origin”.
This second paragraph is specifically pointed out that “different treatment of Origin request headers” is not added at the same time without adding Vary: The Origin header will cause the problem of cache confusion.

The vary problem does not exist in nginx and kangle web server. Only cloudflare has an exception

This topic was automatically closed after 14 days. New replies are no longer allowed.