Object Storage Service (OSS) provides the back-to-origin function to meet your requirements, such as hot data migration and specific request redirection. If the data you request from OSS does not exist, the back-to-origin function allows OSS to retrieve the correct data from the origin specified in the back-to-origin rule. OSS provides two back-to-origin modes: mirroring and redirection.

Note
  • You can configure up to 20 back-to-origin rules, which are implemented in a sequence that they are configured.
  • In regions outside China, the default queries per second (QPS) of mirroring-based back-to-origin is 1,000 and the default bandwidth is 1 Gbit/s. In regions inside China, the default QPS of mirroring-based back-to-origin is 2,000 and the default bandwidth is 2 Gbit/s.
  • For more information about API operations used to configure back-to-origin rules, see GetBucketWebsite.

Implementation modes

Implementation mode Description
Console A user-friendly and intuitive web application
ossutil A high-performance command-line tool

Mirroring-based back-to-origin

After you configure mirroring-based back-to-origin rules for a bucket, you can call the GetObject operation to obtain an object that does not exist in the bucket. This operation allows OSS to retrieve the object based on the origin specified in the rules, returns the object, and stores the object in OSS. The following figure shows the detailed process of mirroring-based back-to-origin.

  • Scenarios

    Mirroring-based back-to-origin is used to migrate data to OSS. This feature allows you to migrate any service that already runs on a user-created origin or in another cloud service to OSS without interrupting services. In this case, you can use mirroring-based back-to-origin to migrate data without stopping the service. For detailed cases, see Seamlessly migrate data from a cloud service to OSS.

  • Detail analysis
    • OSS performs mirroring-based back-to-origin to retrieve an object from the origin only when GetObject returns 404.
    • The URL used by OSS to obtain an object is in MirrorURL+object format, in which object indicates the name of the requested object. For example, the origin URL configured for a bucket is http://aliyun.com, and the requested object abc/123.jpg is not in the bucket. OSS obtains the object from http://aliyun.com/abc/123.jpg, and stores the object as abc/123.jpg.
    • OSS does not send the header information transmitted by a user to the origin. Whether OSS sends the querystring information to the origin depends on the back-to-origin rules configured in the OSS console.
    • If the origin returns chunked-encoded data, OSS also returns chunked-encoded data to the user.
    • OSS returns and stores the following header information received from the origin:
      Content-Type
      Content-Encoding
      Content-Disposition
      Cache-Control
      Expires
      Content-Language
      Access-Control-Allow-Origin
    • When returning objects obtained by using mirroring-based back-to-origin, OSS adds the x-oss-tag response header and sets its value to MIRROR + Space + url_decode (back-to-origin URL). Example:
      x-oss-tag:MIRROR http%3a%2f%2fwww.example-domain.com%2fdir1%2fimage%2fexample_object.jpg
      After you obtain an object from the origin, this header is added to the response when the object is downloaded. This header indicates that the object is obtained by using mirroring-based back-to-origin.
    • After OSS obtains an object by using mirroring-based back-to-origin and the object is modified in the origin, OSS does not update the obtained object. This is because the object is stored in OSS and does not meet the conditions for mirroring-based back-to-origin.
    • If a requested object is not found in the origin, HTTP status code 404 is returned to OSS and OSS returns the same status code to the user. If the origin returns a non-200 HTTP status code to indicate an error, such as object retrieval failures due to network-related errors, OSS returns HTTP status code 424 to users with the error code MirrorFailed.

Redirection-based back-to-origin

Redirection-based back-to-origin enables OSS to return a redirect response with status code 3xx based on the specified back-to-origin conditions and corresponding redirection configurations. You can use this feature to redirect objects and develop various services based on redirection. The following figure shows the process of redirection-based back-to-origin.

Redirection-based back-to-origin is applicable to the following scenarios:
  • Seamless data migration from other data sources to OSS

    When you use redirection-based back-to-origin to migrate data from your data source to OSS asynchronously, OSS returns a 302 redirect request by using URL rewrite for the data that is not migrated to OSS. Your client then reads the data from your data source based on the Location value in the 302 redirect request.

  • Page redirection

    For example, you can use redirection-based back-to-origin to hide objects whose names contain a certain prefix and return a specific page to visitors.

  • Page redirection for a 404 or 500 error

    You can use redirection-based back-to-origin to redirect users to a preset error page when a 404 or 500 error occurs. This method can prevent OSS from exposing system errors to users.