Configure back-to-origin

If a client requests an object that does not exist in a bucket, KS3 can obtain the object from the origin server based on back-to-origin rules. KS3 supports mirroring-based back-to-origin and redirection-based back-to-origin to meet your requirements for hot data migration and redirection of specific requests.

1. Mirroring-based back-to-origin

If a client calls the GET Object operation to request an object that does not exist in a bucket, KS3 requests the object from the origin server. After KS3 obtains the object, KS3 saves the object to the bucket and returns the object to the client, as shown in the following figure.

• Scenarios
  The mirroring-based back-to-origin service is used to seamlessly migrate data to KS3. For example, you have a service running on your self-built origin servers or other cloud products. As your business grows, you need to migrate data to KS3 without interrupting the service. In this case, you can use the mirroring-based back-to-origin service to ensure normal business operation during data migration.

• Usage notes

  • Trigger of mirroring-based back-to-origin
    If a client calls the GET Object operation to request an object that does not exist in a bucket, and mirroring-based back-to-origin rules are configured for the object, mirroring-based back-to-origin is triggered when a mirroring-based back-to-origin rule is met.

  • Rules for returning request failures
    If the origin server returns the HTTP status code 404, indicating that the object does not exist on the origin server, KS3 also returns the HTTP status code 404 to the client. If the origin server returns an HTTP status code other than 404 or 200, indicating failures to obtain the object due to reasons such as network errors, KS3 returns the HTTP status code 424 to the client with the error code of MirrorFailed. If the original server returns the HTTP status code 3xx (301 or 302), KS3 determines whether to obtain the object by following the 3xx redirect request based on back-to-origin rules.

  • Object update rule
    After KS3 obtains an object from the origin server and stores it in a bucket, KS3 does not update the object stored in the bucket when the source object is updated on the origin server.

  • Metadata of the object obtained from the origin server

    Content-Type
    Content-Disposition 
    Cache-Control 
    Expires
    

2. Redirection-based back-to-origin

If a client requests an object that does not exist in a bucket, KS3 returns a 3xx redirect request to the client based on the redirection-based back-to-origin configuration, as shown in the following figure.

• Scenarios
  • Seamlessly migrate data from other sources to KS3
    During an asynchronous data migration from your data source to KS3, KS3 returns a 302 redirect request by using URL rewrite for the data that has not been migrated to KS3. Your client then retrieves the data from your data source based on the Location value in the 302 redirect request.
  • Configure a page redirect
    For example, if you want to hide objects whose names start with the specific prefix, you can use this page to redirect users to a special page.
  • Configure a page redirect upon a 404 error
    You can redirect users to a preset page if a 404 error occurs. This method can prevent KS3 from exposing system errors to users.