请选择
Edge Acceleration
  • Site Acceleration
    • Overview
    • Access Control
      • Token Authentication
    • File Optimization
      • Smart Compression
    • Network Optimization
      • HTTP/2
      • HTTP/3(QUIC)
        • Overview
        • Enable HTTP/3
        • QUIC SDK
          • SDK Overview
          • SDK Download and Integration
          • Sample Code
            • Android
            • iOS
          • API Documentation
            • Android
            • iOS
      • IPv6 Access
      • Maximum Upload Size
      • WebSocket
      • Client IP Geolocation Header
      • Client IP Geographical Location
      • gRPC
    • URL Rewrite
      • Access URL Redirection
      • Origin-Pull URL Rewrite
    • Modifying Header
      • Modifying HTTP Response Headers
      • Modifying HTTP Request Headers
    • Custom Error Page
    • Request and Response Actions
      • Processing order
      • Default HTTP Headers of Origin-Pull Requests
      • Default HTTP Response Headers
  • Smart Acceleration
  • L4 Proxy
    • Overview
    • Creating an L4 Proxy Instance
    • Modifying an L4 Proxy Instance
    • Disabling or Deleting an L4 Proxy Instance
    • Batch Configuring Forwarding Rules
    • Obtaining Real Client IPs
      • Obtaining Real TCP Client IPs via TOA
      • Obtaining Real Client IPs Through Protocol V1/V2
        • Overview
        • Method 1: Obtaining Real Client IPs Through Nginx
        • Method 2: Parsing Real Client IPs on Application Server
        • Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
      • Transmitting Client Real IP via SPP Protocol
  • Edge DNS
    • Hosting DNS Records
      • Modifying DNS Servers
      • Configuring DNS Records
      • Advanced DNS Configuration
    • Domain Connection
      • Adding A Domain Name for Acceleration
      • Ownership Verification
      • Modifying CNAME Records
    • Domain alias
      • Overview
      • Configuration Guide
      • Batch Connecting SaaS Domain Names
      • Configuring Alias Domain Names for Disaster Recovery
    • Traffic Scheduling
      • Traffic Scheduling Management
    • Origin Configuration
      • Load Balancing
        • Overview
        • Quickly Create Load Balancers
        • Health Check Policies
        • Viewing the Health Status of Origin Server
        • Related References
          • Load Balancing-Related Concepts
          • Introduction to Request Retry Strategy
      • Origin Group Configuration
      • Origin-pull configuration
        • Configuring Origin-Pull HTTPS
        • Host Header Rewrite
        • Controlling Origin-pull Requests
        • Redirect Following During Origin-Pull
        • HTTP/2 Origin-Pull
        • Range GETs
      • Related References
        • ld Version Origin Group Compatible Related Issues
        • VOD Origin Server Details
      • Collect EdgeOne origin-pull node IP
  • Edge Cache
    • Overview
    • EdgeOne Cache Rules
      • Content Cache Rules
      • Cache Key Introduction
      • Vary Feature
    • Cache Configuration
      • Custom Cache Key
      • Node Cache TTL
      • Status Code Cache TTL
      • Browser Cache TTL
      • Offline Caching
      • Cache Prefresh
    • Clear and Preheat Cach
      • Cache Purge
      • URL Pre-Warming
    • How to improve the Cache Hit Rate of EdgeOne
  • Rules Engine
    • Overview
    • Supported Matching Types and Actions
    • Rule Management
    • variables
  • Image Processing
Docs Overview/
Edge Acceleration/
Edge Cache/
EdgeOne Cache Rules/
Vary Feature/

Vary Feature

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.