我需要使用根据 Origin请求头动态计算出的Access-Control-Allow-Origin，一定要始终加上Vary: Origin，以便返回不同的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
这第二段是特别指出“区分对待有无 Origin 请求头”的同时不加Vary:Origin头会引起缓存错乱问题。
vary问题在nginx，kangle web server中都不存在这些问题现象。只有cloudflare 出现了异常
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