Configure back-to-origin

Last updated:2021-09-14 16:17:54

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.

镜像回源1.png

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

回源2.png

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

Did you find the above information helpful?

Unhelpful
Mostly Unhelpful
A little helpful
Helpful
Very helpful

What might be the problems?

Insufficient
Outdated
Unclear or awkward
Redundant or clumsy
Lack of context for the complex system or functionality

More suggestions

0/200

Please give us your feedback.

Submitted

Thank you for your feedback.

问题反馈