Via back-to-origin setting, the back-to-origin reading is applied to the data getting request via the image method, to meet your hot migration demand of data.
After configuring the image back-to-origin rule, you need to match each Get request URL to OSS and conduct back-to-origin according to the rules set by you. At most 5 rules can be configured. Please match the rules in order, until an effective one is matched.
If the image write-back function is configured, when the Get operation is made to an absent file, OSS will request such file from the source address. Then the file will be returned to the user and written to OSS at the same time.
The image back-to-origin is mainly used for seamlessly migrating data to JD Cloud OSS. In other words, if the service is running in the self-built origin server or other cloud products, when it needs to migrate such service to JD Cloud OSS without interrupting the service, the migration can be implemented by using the image write-back function. The specific scenario analysis is as follows:
The origin server has a batch of cold data, while continuously producing new hot data.
The cold data can be migrated to OSS via a migration tool at first, while the image back-to-origin can be configured and the origin server address can be configured to OSS. After the domain is switched to JD Cloud OSS (or JD Cloud CDN, or back-to-origin OSS), even if a part of the newly-produced data are not migrated, they can still be normally accessed on OSS, and the file will be saved in OSS upon one access. After the domain is switched, the origin server will produce no data. In such case, please scan again, import the data which have not been imported yet into OSS at one time and then delete the image write-back configuration.
If the IP address is used as the back-to-origin of configuration, then the domain can be migrated to OSS first and then imaged to the origin server. However, if a domain is configured, as the domain itself will be resolved in OSS or CDN, then the image will be out of action. In such case, you can apply for using another domain as the origin server of the image and such domain and the domain in service will be resolved to the same IP address. By doing so, the service domain can be continuously imaged to the origin server when being migrated.
Only a part of the origin server traffic is switched to OSS or CDN, and the origin server itself is producing data continually.
The migration method is similar to the method above. When the traffic is switched to OSS, do not delete the image back-to-origin configuration. In such case, the traffic switched to OSS or CDN can still get the origin server data.
Detail Analysis:
Content-Type Content-Encoding Content-Disposition Cache-Control Expires
Description Back-to-origin address does not support to configure OSS Intranet domain.
Reference: Set Image Back-to-origin
(1) Login to the Console->Object Storage Service->Space Management->Enter a Bucket->Space Settings->Image back-to-origin
(2) Click a setting rule to enter the image back-to-origin rule list page.
(3) Click Create Rules, set back-to-origin conditions and back-to-origin address in the creation pop-up. You can set whether carry request character string or not and set whether the 3xx request response is followed with the origin server re-direction request or not according to real demands. Meanwhile, customized pass-through, filtering or modification is supported by setting HTTP header transmission rules.
Note:
The image back-to-origin will be normally charged as per the Internet traffic.
The back-to-origin address is the required item, and domain, IP and port are supported.
The character string carrying requests will transmit queryString in the OSS requests to the origin server
The 3xx request response setting will get resources with the origin server re-direction request by default and save the resource on OSS. If no item is checked, OSS will pass through 3XX response, without acquiring resources.
HTTP header Transmission Rules: The header information transmitted to OSS by default will not be transmitted to the origin server. You are allowed to specify the header parameters to be enabled, disabled and set by customizing rules,
The configuration example is as follows:
Based on the above configuration, requests (the HTTP header part) sent to OSS by the user are as follows:
GET /object host : bucket.s3.cn-north-1.jcloudcs.com a-header : 111 b-header : 222 c-header : 333
GET /object host : source.com a-header : 111 c-header : 000
The setting of HTTP header transmission rule is not supported by the following HTTP header types:
header with the following prefixes: x-oss- All standard HTTP headers, for example: authorization2 authorization content-length range date
(4) Click OK and submit rules.
Login to the Console->Object Storage Service->Space Management->Enter a Bucket->Space Settings->Image back-to-origin