Overview

To configure a bucket for static website hosting, add the site configuration to the bucket. The configuration includes the following information:

Index document

When you enter a URL such as http://example.com, you are not requesting a specific page. In this case, the Web server will provide a default page that contains the directory that stores the requested website content. This default page is called an index document, and in most cases it is named as index.html. When you configure a bucket for website hosting, you must specify an index document. When a request is sent to the root domain or any subfolder, OBS returns this index document.

Error document

If an error occurs, OBS returns an HTML error document. For 4XX errors, you can selectively provide your own customized error document. You can provide other guides to your users in this document.

Redirection of all requests

If the root domain is example.com and you need to respond to requests from http://example.com and http://www.example.com, you can create two buckets named example.com and www.example.com. Then you can retain the website content in only one bucket (such as example.com), and configure the other bucket to redirect all requests to the example.com bucket.

Redirection based on advanced conditions

You can redirect requests based on the specific object name or prefix in the request, or based on the response code. For example, assume that you delete or rename an object in a bucket. You can add a routing rule that redirects requests to other objects.

The syntax format is as follows by setting redirection rules of specific requests:

<WebsiteConfiguration> 
    <IndexDocument> 
        <Suffix>index.html</Suffix></IndexDocument> 
    <ErrorDocument> 
        <Key>SomeErrorDocument.html</Key> 
    </ErrorDocument> 
    <RoutingRules> 
............RoutingRules......
    </RoutingRules> 
</WebsiteConfiguration>

The syntax format of RoutingRules is as follows. The content in square brackets is optional.

<RoutingRules> = 
    <RoutingRules> 
        <RoutingRule>...</RoutingRule> 
        [<RoutingRule>...</RoutingRule> ...] 
    </RoutingRules> 

<RoutingRule> = 
    <RoutingRule> 
        [ <Condition>...</Condition> ] 
        <Redirect>...</Redirect> 
    </RoutingRule> 

<Condition> = 
    <Condition>  
        [ <KeyPrefixEquals>...</KeyPrefixEquals> ] 
        [ <HttpErrorCodeReturnedEquals>...</HttpErrorCodeReturnedEquals> ] 
    </Condition> 

<Redirect> = 
    <Redirect> 
        [ <HostName>...</HostName> ] 
        [ <Protocol>...</Protocol> ] 
        [ <ReplaceKeyPrefixWith>...</ReplaceKeyPrefixWith> ] 
        [ <ReplaceKeyWith>...</ReplaceKeyWith> ][ 
        <HttpRedirectCode>...</HttpRedirectCode> ] 
    </Redirect>

Examples:

Example 1: Modifying the object name prefix for redirection.

Assume that your bucket contains the following objects:

index.html

docs/article1.html

docs/article2.html

You decide to change the folder name from docs/ to documents/. After the modification, the request for an object with prefix /docs needs to be redirected to another with documents/. For example, the request for docs/article1.html needs to be redirected to documents/article1.html.

In this case, you can add the following routing rules to the website configuration:

 <RoutingRules> 
    <RoutingRule> 
    <Condition> 
      <KeyPrefixEquals>docs/</KeyPrefixEquals> 
    </Condition> 
    <Redirect> 
      <ReplaceKeyPrefixWith>documents/</ReplaceKeyPrefixWith> 
    </Redirect> 
    </RoutingRule> 
  </RoutingRules>

Example 2: Redirecting requests destined for deleted folders to a specified page

Assume that you have deleted the images/ folder, that is, you have deleted all objects whose object name prefix is images/. You can add a routing rule that redirects the requests of all objects whose prefix is images/ to the page named folderdeleted.html.

<RoutingRules> 
    <RoutingRule> 
    <Condition> 
       <KeyPrefixEquals>images/</KeyPrefixEquals> 
    </Condition> 
    <Redirect> 
      <ReplaceKeyWith>folderdeleted.html</ReplaceKeyWith> 
    </Redirect> 
    </RoutingRule> 
  </RoutingRules>

Example 3: Redirecting for HTTP errors

Assume that the requested object is not found, and the request needs to be redirected to www.example.com. You can add redirection rules so that site visitors can redirect to www.example.com when HTTP status code 404 (not found) is returned. The following example also inserts the object name prefix report-404/ into redirection. For example, if you request the page ExamplePage.html and it causes an HTTP 404 error, the request will be redirected to the page report-404/ExamplePage.html on the www.example.com. If there is no routing rule and HTTP error 404 occurs, the error document specified in the configuration is returned.

<RoutingRules> 
    <RoutingRule> 
    <Condition> 
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals > 
    </Condition> 
    <Redirect> 
      <HostName>www.example.com</HostName> 
      <ReplaceKeyPrefixWith>report-404/</ReplaceKeyPrefixWith> 
    </Redirect> 
    </RoutingRule> 
  </RoutingRules>

http://bucketname.obs-website.example.com
http://bucketname.obs-website.example.com

Permissions required for website access

When you configure a bucket as a website, you must make the object to be provided public and accessible. To perform this operation, you need to write a bucket policy that grants GetObject permissions to everyone. If the object requested by the user does not exist on the terminal node of the website, OBS returns the HTTP response code 404 Not Found. If the object exists but you do not grant read permission for the object, the website terminal node returns HTTP response code 403 Access Denied. Users can use this response code to infer whether a particular object exists. If you do not need this function, do not enable the bucket website support.

The following example bucket policy grants each person the permission to access objects in a specified folder. For details about bucket policies, see Bucket Policy.

{ 
   "Statement":[{ 
    "Sid":"PublicReadGetObject", 
      "Effect":"Allow", 
      "Principal": {"ID":"*"}, 
      "Action":["GetObject"], 
      "Resource":["example-bucket/*"  ] 
    } 
  ] 
}

A bucket policy applies only to objects owned by a bucket owner. If the bucket contains objects that are not owned by the bucket owner, use object ACLs to grant the public READ permission to the objects.

You can use bucket policies or object ACLs to grant public read permissions to your objects. To use ACLs to make objects public and accessible, you can grant READ permission to everyone, as shown in the following authorization elements. You can add the authorization element to object ACLs. For details about managing ACLs, see ACL.

<Grant> 
  <Grantee> 
    <Canned>Everyone</Canned> 
  </Grantee> 
  <Permission>READ</Permission> 
</Grant>