Scenarios

For details, see Back to Source.

You can create back-to-source rules or replicate existing back-to-source rules from another bucket.

Limitations and Constraints

For details, see Back to Source.

Creating a Mirroring Back-to-Source Rule

1. In the navigation pane on the left of OBS Console, choose Object Storage.
2. In the bucket list, click a bucket name, and then the Overview page of the bucket is displayed.
3. In the navigation pane on the left, choose Back to Source. The back-to-source rule list is displayed.
4. Click Create.
   Figure 1 Creating a mirroring back-to-source rule
   

5. Table 1 lists the parameters required for configuring a mirroring back-to-source rule.

   Table 1 Parameters in a mirroring back-to-source rule

   Parameter	Description
   Resource Type	Type of the source site resources Mirroring back-to-source rules support only public resources, namely resources that can be accessed through public network domain names.
   Back-to-Source Condition	Conditions that trigger the back-to-source rule. A mirroring back-to-source rule is triggered when the following conditions are met: The requested object starts with the specified file name prefix, and an HTTP status code 404 is returned because the object is not found in the bucket. Rules for specifying a file name prefix: The specified file name prefix cannot exceed 1023 characters. The specified file name prefix cannot contain or overlap with any other file name prefix specified for an existing rule. If no file name prefix is specified, the rule applies to all files that do not meet the conditions of other back-to-source rules configured for the bucket. A bucket can have only one back-to-source rule that does not have a specified file name prefix. For example, if the file name prefix is set to 123/, the rule is triggered when the 123/456.txt file is requested but not available in the bucket.
   Add Prefix or Suffix	When OBS requests data from the source site, the prefix or suffix is added in front of or after the name of the requested object. However, the object returned to OBS and the client keeps its original name without the added prefix or suffix. Example: A client requests abc.txt from OBS, which triggers the back-to-source rule. If the specified prefix is 123, OBS requests 123abc.txt from the source site. However, the object is still downloaded as abc.txt to OBS and then returned to the client.
   Replace Prefix With	OBS uses the specified prefix to replace the file name prefix set in the back-to-source condition when it requests data from the source site. However, the object returned to OBS and the client keeps its original name without this prefix. Example: The file name prefix is set to 123 as the back-to-source condition and the replacement prefix is set to abc. When the client requests 123456.txt, the back-to-source rule is triggered. Then OBS requests abc456.txt from the source site. However, the obtained object is still saved as 123456.txt in OBS and returned to the client.
   Source URL	Source site address. You can set active sites and standby sites. The active site address is preferentially used during the back-to-source process. If multiple active site addresses are configured, all active sites are accessed in polling mode. If two or more active site addresses are configured, when the first request to an active address fails and the retry conditions are met, the request will retry another active site address. Configure at least one active site. Up to five active sites are supported. If you fail to retrieve content from all active sites, the request will try standby sites. Format: http(https)://source domain name/static path The source domain name is the domain name of the source site. If the source site is a bucket that can be accessed over HTTP network, the address is the bucket domain name. If the source site is a private bucket provided by other cloud vendors, the address is a region domain name address. The static path indicates the directory where the target file resides. For example, if the static path is 123/, the target file is in the 123/ directory.
   Retry Condition	Condition when a retry is triggered. Error codes starting with 4XX and 4 cannot be configured together. Error codes starting with 5XX and 5 cannot be configured together. A maximum of 20 error codes can be configured.
   Carry Request String	When this function is enabled, query parameters in the request URL are passed to the source site.
   Redirect Request	When this function is enabled, the request will follow the 3xx redirection response, if redirection is configured for the source site, to fetch the requested resource and save the resource to OBS. A request can follow a maximum of 10 redirections.
   HTTP Header Pass Rule	You can specify the HTTP header parameters that can be passed to the source site when a request sent to OBS triggers the mirroring back-to-source rule. References provides a configuration example and lists the HTTP headers that are not supported. Pass all parameters/Pass specified parameters: Set the HTTP header parameters that can be passed. Do not pass specified parameters: Set the HTTP header parameters that cannot be passed. In this case, OBS does not pass the specified headers to the source site. If a header is specified for both the pass and do-not-pass categories, it is deemed as a do-not-pass parameter. Configure custom parameters: You can set a custom value for a specified header. If a client request carries this header, OBS changes the header value to the custom value before passing it to the source site.
   IAM Agency	An IAM agency is required to delegate OBS to obtain data from the source site. The agency must grant OBS the Tenant Administrator permission, with an unlimited validity period. If no appropriate IAM agency is available, create one. For details, see Creating an IAM Agency.

6. Click OK.

Replicating Mirroring Back-to-Source Rules

1. In the navigation pane on the left of OBS Console, choose Object Storage.
2. In the bucket list, click a bucket name, and then the Overview page of the bucket is displayed.
3. In the navigation pane on the left, choose Back to Source. The back-to-source rule list is displayed.
4. Click Replicate.
5. Select a replication source, that is, the source bucket for which the back-to-source rules were configured.
   

   • The back-to-source rules replicated from a source bucket will not overwrite existing rules in the destination bucket, and any that conflict with the existing ones will not be replicated.
   • The version of both the source and destination buckets must be 3.0.
   • Before replicating the back-to-source rules, you can change their source URL. For details about the source URL configuration, see Table 1.
   • You can remove the rules that you do not want to replicate.
   • There can be five back-to-source rules at most in a bucket. If the number of rules you will replicate plus the number of existing rules in the destination bucket exceeds five, the replication will fail. Before replicating the rules, delete some if necessary.
   Figure 2 Replicating back-to-source rules
   

6. Click OK to replicate the rules to the destination bucket.

References

Example for configuring an HTTP header pass rule:

Assume that the parameters are set as shown in Figure 3.

Figure 3 Configuring an HTTP header pass rule

Based on the preceding configuration, if the header of the request sent to OBS is as follows:

GET /ObjectName HTTP/1.1 
Host: bucketname.obs.cn-north-4.myhuaweicloud.com 
aaa:aaa
bbb:bbb
ccc:ccc

OBS sends the following request to the source site when the back-to-source rule is triggered:

GET /ObjectName HTTP/1.1 
Host: source.com 
aaa:aaa
ccc:111

The following HTTP headers cannot be passed to the source site:

1. HTTP headers starting with the following prefixes:
   • x-obs-
2. All standard HTTP headers, for example:
   • Content-Length
   • Authorization2
   • Authorization
   • Range
   • Date