Mirroring-based back-to-origin

If a client requests an object that does not exist in a bucket, KS3 requests the object from the origin server and returns the object to the client. If the client requests the full object, KS3 requests the object from the origin server, returns the object to the client, and stores the object in KS3. If the client sends a range request for a part of the object, KS3 requests the required data from the origin server, returns the data to the client, and asynchronously pulls the object to KS3.

Notes:

1. You can configure up to 20 back-to-origin rules. The rules are used to match a request in the sequence that they are configured.

2. You can use the mirroring-based back-to-origin service to migrate an object of up to 50 GB in size.

3. This service is supported only in the CN North 1(Beijing) region.

4. To use this service, contact your business representative or submit a ticket.

Important:

1. The data pulled to KS3 is stored by using the Standard storage class by default.

2. The object name customization feature of KS3 does not take effect on the objects that are pulled to KS3 by using the mirroring-based back-to-origin service.

3. 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.

4. Original image protection does not take effect on the objects that are pulled to KS3 by using the mirroring-based back-to-origin service.

5. Server-side encryption (SSE) and server-side encryption with customer-provided encryption keys (SSE-C) do not take effect on the objects that are pulled to KS3 by using the mirroring-based back-to-origin service.

Operation methods

• Console operations: Configure mirroring-based back-to-origin
• API operations:
  • PUT BucketMirror: You can call this operation to configure or update mirroring-based back-to-origin rules for a specified bucket.
  • GET BucketMirror: You can call this operation to obtain the mirroring-based and redirection-based back-to-origin configurations of a specified bucket.
  • DELETE BucketMirror: You can call this operation to delete the back-to-origin configurations of a specified bucket.

Mirroring methods

Processes of mirroring-based back-to-origin

If a client requests an object that does not exist in a bucket, KS3 sends a request to the origin address for the object. To prevent a long waiting time for obtaining the entire object, KS3 pulls a part of the object from the origin server in streaming mode. After the origin server returns data, KS3 returns the data to the client and stores the data in the corresponding bucket. The following figures show the processes of mirroring-based back-to-origin.

1. Process for a full object request

2. Process for a range request

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

• HTTP request rules Headers contained in the request sent to KS3 are not contained in the request sent by KS3 to the origin server. Whether KS3 sends the QueryString information to the origin server depends on the back-to-origin rules configured in the KS3 console. For more information about how to configure header transfer rules in the KS3 console, see Configure mirroring-based back-to-origin. If the origin server returns chunked-encoded data, KS3 also returns chunked-encoded data to the client.

Example of matching multiple rules

Assume that multiple rules with the same or partially overlapping back-to-origin conditions are configured:

Rule 1: Access test.com when the 404 error is returned for all objects.

Rule 2: Access 141.0.0.12 when the 404 error is returned for all objects.

Rule 3: Access back.com when the 404 error is returned for objects with the name prefix 333.

Processing of KS3:

1. KS3 matches the request against Rule 1. If data can be properly pulled from test.com, KS3 no longer matches the request against Rule 2.

2. KS3 matches the request against Rule 1. However, test.com is unavailable when the back-to-origin service of KS3 attempts to access it. Then, KS3 attempts to access 141.0.0.12 configured in Rule 2.

3. If 141.0.0.12 configured in Rule 2 is also unavailable and the object name prefix is 333, KS3 continues to access back.com in Rule 3. If the object name prefix is not 333, KS3 returns the 404 error.