Configure range origin fetch

Updated at:

Range origin fetch enables a CDN point of presence (POP) to include a Range header in origin requests so that the origin server returns only the specified portion of a resource. This improves file delivery efficiency, reduces back-to-origin traffic, lowers the load on your origin server, and speeds up response times.

Background

The HTTP Range header specifies which part of a resource to retrieve. For example, Range: bytes=0-100 requests the first 101 bytes of a file.

After you enable range origin fetch, when a POP receives a request for a resource that is not cached or has expired, the POP fetches only the required segments from the origin server by using Range requests and caches them locally.

How range origin fetch works:

image

Usage notes

Before you enable range origin fetch:

  • Make sure your origin server supports Range requests and can respond with 206 Partial Content. If it does not, enabling this feature may cause caching issues or request failures.

  • Range origin fetch is disabled by default.

  • Multipart Ranges is disabled by default and is not enabled by range origin fetch. To enable it, submit a ticket.

  • Enabling range origin fetch increases origin fetch QPS, which may trigger rate limiting on your origin server. To avoid this, call the DescribeL2VipsByDomain operation to retrieve the IP addresses of origin-pull POPs and add them to your origin server's IP allowlist.

Use cases for large files

CDN supports progressive streaming for large files such as MP4. The behavior depends on your origin server's Range request support and the origin fetch mode configured in the CDN console:

  • Scenario 1: Origin server supports Range requests and range origin fetch is enabled

    When the client sends a Range request and range origin fetch is enabled, the POP fetches only the requested data range from the origin server and returns it to the client. The POP does not wait for the entire file to download. Progressive streaming is supported.

  • Scenario 2: Client does not send a Range request

    If a client requests a complete file without a Range header, the POP requests the complete file from the origin and streams it to the client. Because the data is forwarded as it is received, the client can start playback immediately (provided that the MP4 moov atom is in the file header), but cannot seek to a position that has not yet been downloaded. In this scenario, the range origin fetch configuration does not affect the client-side transfer behavior.

  • Scenario 3: Origin server does not support Range requests

    If the origin server does not support Range requests and cannot respond with 206, range origin fetch has no effect even if enabled. The POP fetches the complete file instead. Verify that your origin server supports Range requests before enabling this feature.

Note

MP4 and similar formats support streaming, but the underlying HTTP transport must support Range requests. Verify that your origin server supports Range requests and select the appropriate origin fetch mode based on your requirements.

Procedure

  1. Log on to the CDN console.

  2. In the left navigation pane, click Domain Names.

  3. On the Domain Names page, find the target domain name and click Manage in the Actions column.

  4. In the domain's navigation pane, click Video.

  5. In the Range Origin Fetch section, click Modify.

  6. Based on the following table, select Do Not Enable Range Origin Fetch, Match Client, or Enable Range Origin Fetch (Recommended for Large File Delivery).

    If you select Match Client or Enable Range Origin Fetch (Recommended for Large File Delivery), you can set the shard size. The default shard size is 512 KB.

    Parameter

    Option

    Description

    Example

    Range Origin Fetch

    Do Not Enable Range Origin Fetch

    By default, Do Not Enable Range Origin Fetch is selected, which means that regardless of whether a client sends a Range request to a CDN POP, the CDN POP requests the entire file during an origin fetch, resulting in low file distribution efficiency for large files.

    For example, if a request from a client to a CDN POP contains Range: bytes=0-100, the CDN POP sends a request to the origin server without the Range parameter. The origin server sends the entire file to the CDN POP. For example, if the file is 10 MB, the origin server sends the 10 MB file to the CDN POP. The CDN POP caches the file that it receives from the origin server and then responds to the client with the content for the Range: bytes=0-100 request.

    Match Client

    After you enable Match Client, if a client sends a Range request to a CDN POP, the CDN POP performs an origin fetch by using a Range request. For the first origin fetch request, the CDN POP requests a data block from your origin server. The size of this block is determined by rounding up the range size from the client's request to the nearest integer multiple of the shard size. All subsequent origin fetch requests use the shard size that you specify.

    For example, when the shard size is 512 KB, if a client sends a request to a CDN POP that contains Range:bytes=0-614399 (which is 600 KB), and the file is not cached on the CDN POP, the first origin fetch retrieves a 1024 KB shard (600 KB rounded up to 1024 KB). For subsequent requests for other uncached shards of the file, the CDN POP accesses the origin server by using a shard size of 512 KB.

    Enable Range Origin Fetch (Recommended for Large File Delivery)

    After Enable Range Origin Fetch (Recommended for Large File Delivery) is enabled, regardless of whether a client sends a Range request to a CDN POP, CDN POPs always use Range requests for origin fetch. All Range requests sent from CDN POPs to the origin server use the shard size that you specify.

    None

    Shard Size

    • 512 KB

    • 1 MB

    • 2 MB

    • 4 MB

    You can set the shard size if you select Match Client or Enable Range Origin Fetch (Recommended for Large File Delivery). The default size is 512 KB.

    1 MB

    Rule Condition

    A rule condition evaluates request parameters to determine whether a configuration applies.

    Important

    When a feature uses rule conditions from the rules engine, execution follows rule condition priority, not feature configuration order.

    • Do not use conditions: Disables conditional rules.

    • You can add or edit conditional rules in Rules engine.

    A rule condition evaluates parameters in a user request to determine whether the configuration applies.

    Do not use

  7. Click OK to save the configuration.

Handling out-of-range HTTP Range requests

When CDN fetches large files from an OSS origin server, issues may occur if OSS responds with cache-control:no-cache or if a client request to CDN triggers Range-based origin fetch. Symptoms include slow downloads, timeouts (~30 seconds), or dropped connections when an out-of-range slice is downloaded.

  • Behavior without a compatibility policy

    For valid Range requests, OSS returns a 206 response with the Content-Range header. For invalid or out-of-bounds Range requests, OSS ignores the Range header, returns a 200 response, and transfers the entire object. Invalid Range request examples:

    Note

    The following examples assume an object size of 1000 bytes (valid range: 0–999). To avoid out-of-bounds ranges, send a HeadObject request to get the object size first.

    • Range: byte=0-499: Invalid format. byte should be bytes.

    • Range: bytes=0-1000: The end byte, 1000, is out of the valid range.

    • Range: bytes=1000-2000: The specified range is out of the valid range.

    • Range: bytes=1000-: The start byte is out of the valid range.

    • Range: bytes=-2000: The specified range is out of the valid range.

    To test Range parameter validity:

    curl -r 0-100 http://xxxx.oss-cn-hangzhou.aliyuncs.com/xx.zip -o /tmp/xx1.zip -v
  • Behavior with a compatibility policy

    Add the x-oss-range-behavior:standard header to an HTTP Range request to change how OSS handles out-of-bounds ranges:

    Note

    The following examples assume an object size of 1000 bytes (valid range: 0–999). If you specify an invalid range, OSS returns an InvalidRange error code. To resolve this, see OSS returns a 416 error. The error message:

    The requested range cannot be satisfied

    • Range: bytes=500-2000: The end byte is out of the valid range. OSS returns the content in the byte range of 500 to 999.

    • Range: bytes=1000-2000: The start byte is out of the valid range. OSS returns a 416 (InvalidRange) error.

    • Range: bytes=1000-: The start byte is out of the valid range. OSS returns a 416 (InvalidRange) error.

    • Range: bytes=-2000: The specified range is out of the valid range. OSS returns the content in the byte range of 0 to 999, which is the complete file.

    HTTP Range request examples:

    Note

    The following examples assume an object size of 1000 bytes (valid range: 0–999).

    • Request the content of an object within the byte range of 0 to 499.

      GET /ObjectName
      Range: bytes=0-499
      Host: bucket.oss-cn-hangzhou.aliyuncs.com
      Date: Fri, 18 Oct 2019 02:51:30 GMT
      Authorization: Signature
      
      206 (Partial Content)
      content-length: 500
      content-range: bytes 0-499/1000
      connection: keep-alive
      etag: "CACF99600561A31D494569C979E6FB81"
      x-oss-request-id: 5DA928B227D52731327DE078
      date: Fri, 18 Oct 2019 02:51:30 GMT
      [500 bytes of object data]
    • Request the content of an object from byte 500 to the end of the file.

      GET /ObjectName
      Range: bytes=500-
      Host: bucket.oss-cn-hangzhou.aliyuncs.com
      Date: Fri, 18 Oct 2019 03:24:39 GMT
      Authorization: Signature
      
      206 (Partial Content)
      content-length: 500
      content-range: bytes 500-999/1000
      etag: "CACF99600561A31D494569C979E6FB81"
      x-oss-request-id: 5DA9307750EBE33332E3720A
      date: Fri, 18 Oct 2019 03:24:39 GMT
      [500 bytes of object data]
    • Request the last 500 bytes of an object.

      GET /ObjectName
      Range: bytes=-500
      Host: bucket.oss-cn-hangzhou.aliyuncs.com
      Date: Fri, 18 Oct 2019 03:23:22 GMT
      Authorization: Signature
      
      206 (Partial Content)
      content-length: 500
      content-range: bytes 500-999/1000
      etag: "CACF99600561A31D494569C979E6FB81"
      x-oss-request-id: 5DA9302A6646AC37397F7039
      date: Fri, 18 Oct 2019 03:23:22 GMT
      [500 bytes of object data]
Note
  • For large file distribution (average file size > 20 MB), configure this setting for CDN and origin fetch to OSS.

  • If access authentication is enabled on your OSS origin server and clients sign origin fetch requests, include the x-oss-range-behavior:standard header in the signature calculation. OSS includes all x-oss- prefixed headers in signature verification. Omitting the x-oss-range-behavior header causes a signature mismatch and request rejection.