Tencent Cloud

Recent Pages

Vary Feature

Last updated: 2024-08-26 16:28:37

Support for Vary
EdgeOne supports the Vary feature, which is currently disabled by default. To enable it, please contact us. Once the feature is enabled, you can simply add a Vary header to the response header in the origin response without any configuration. For more information about the standards of a Vary header, see Vary.
Note:
If your domain name was created before 00:00:00 on June 13, 2024, the Vary feature was enabled and supported for the domain name by default.
What Is the Vary Feature?
Vary is an HTTP response header newly added in HTTP/1.1. When a client uses the same URL to initiates requests to an origin server, if the origin server has response files of different versions, requested resources may be cached by an intermediary cache system, such as the browser cache and content distribution network (CDN) cache, and the origin server may fail to respond to requests by scenario. To prevent this condition, the origin server can use a Vary header in the HTTP response to notify the intermediary cache system of the specific request header for distinguishing the version of the cached content.
For example, if the client requests are all targeting at https://www.example.com/test.pdf, and the origin server uses Vary: Accept-Language in the HTTP response header to distinguish the client language, EdgeOne will generate caches of different versions based on the Accept-Language content specified in the client requests.
When User A initiates a request with the URL https://www.example.com/test.pdf, and the request contains the request header Accept-Language:zh-cn, EdgeOne responds to the request with File A.
When User B initiates a request with the URL https://www.example.com/test.pdf, and the request contains the request header Accept-Language:en-US, EdgeOne responds to the request with File B.
﻿
Application Scenarios of Vary
You can flexibly use the Vary header to control the files requiring different cached file versions according to the HTTP request header and solve issues in the following scenarios:
Scenario I: Distinguishing response files by client type when the request URLs are the same
When a website serves user access from both PCs and mobile devices at the same URL for user convenience, due to the different screen resolutions between PCs and mobile devices, the frontend needs to adapt the image content to the access source. In this case, the User-Agent header carried in the user requests is used to distinguish the access source type, ensuring requests from PCs are responded with Image A and requests from mobile devices are responded with Image B. In this case, the origin server can add the Vary:User-Agent header to the responses to instruct Edge nodes to distinguish the cached versions according to the User-Agent header in the user requests.
﻿
Scenario II: Responding to cross-domain access according to the access source when the request URLs are the same
When the same image file in a page cache is referenced by both Domain A and Domain B, to avoid cross-domain errors, Access-Control-Allow-Origin is usually added to the response file in the origin server to allow cross-domain access. However, when the current file is cached, both cross-domain headers may be cached or a cross-domain access error may occur. In this case, the origin server can add the Vary:origin header to instruct Edge nodes to distinguish the cached versions according to the Origin header in the user requests, while responding the Access-Control-Allow-Origin cross-domain header.
﻿
﻿