Static Website Hosting
Precautions
For security and compliance purposes, using static website hosting through the default OBS domain name (bucket domain name or static website domain name) will be prohibited by OBS. When you use such domain name to access web pages through a browser, no content will be displayed, instead, the content is downloaded as an attachment.
However, you can still use static website hosting through a user-defined domain name and can preview the web page content.
Scenarios
You can use OBS to host your static website, for which you can also configure an index document, error document, and page direction. You can upload the content files of the static website to your bucket in OBS and configure a read permission to anonymous users for these files, and then configure the static website hosting mode for your bucket to host your static websites in OBS.
Static websites contain static web pages and some scripts that can run on clients, such as JavaScript and Flash. Different from static websites, dynamic websites rely on servers to process scripts, including PHP, JSP, and ASP.NET. OBS does not support scripts that run on servers.
After static website hosting is enabled, you can access objects in a bucket using either of the following methods:
- Resource management: You can access objects in a bucket through a common domain name. You can use APIs or SDKs and default OBS domain names with endpoints contained to perform common operations on buckets and objects, such as upload, download, deletion, and listing.
- Static website: You can access objects in a bucket by using a specific domain name. In this mode, display of the index page, error pages and requested pages is implemented according to the configured static domain name hosting rules.
The configuration of static website hosting takes effect within two minutes. After it takes effect, you can access static resources using the following URLs:
https://Static website domain name/Object name http://Static website domain name/Object name
A static website domain name is in the BucketName.obs-website.Endpoint format. BucketName indicates the name of a bucket, and Endpoint indicates the OBS domain name of the region where the bucket is located.
Avoid using periods (.) in the destination bucket name. Otherwise, failures in client authentication certificate may occur when users use HTTPS for access.
To allow your clients to access the content on the website terminal node, you must make all of your content public and accessible. You can use bucket policies or ACLs on objects to grant permissions.
The following table lists the differences between the resource management mode and static website mode.
Major Difference |
Resource Management |
Static Website |
---|---|---|
Access control |
Both public content and private content are supported. |
Only public content is supported. |
Error message processing |
An error response in XML format is returned. |
An HTML document is returned. |
Redirection support |
N/A |
Both object-level and bucket-level redirection are supported. |
Supported request |
Operations on all buckets and objects are supported. |
Only GET and HEAD requests on objects are supported. |
Response to GET and HEAD requests of bucket root level |
List of object keys in a bucket is returned. |
Index file specified in the configuration is returned. |
Redirection Overview
When using static website hosting, you can configure redirection to redirect specific or all requests.
If the structure, address, or file name extension of a website is changed, users will fail to access the website using the old address (such as the address saved in the folder of favorites), and the 404 error message will be returned. In this case, you can configure redirection for the website to redirect user access requests to the specified page instead of returning the 404 error page.
Typical configurations include:
- Redirecting all requests to another website.
- Redirecting specific requests based on redirection rules.
Configuring Static Website Hosting
Overview
If you want to use a bucket to host static websites, add the website 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 provide your own customized error document, or 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>
For request elements required for redirecting all requests sent to a specified website and for setting redirection rules, see Configuring Static Website Hosting for a Bucket – Request Elements
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 sent to 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 when HTTP errors occur
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>
Index Document Support
An index document is a web page returned when a request is sent to the root of a site or any subfolder. For example, if the user enters http://www.example.com in the browser, the user does not request any specific page. In this case, OBS provides index documents, which are sometimes referred to as default pages.
When configuring your bucket as a website, provide the name of the index document. You must upload the object with this name and configure it to be public and accessible.
Trailing slash in the root URL is optional. For example, if you configure an index.html website as an index document, index.html will be returned to any of the following URLs:
http://bucketname.obs-website.example.com/ http://bucketname.obs-website.example.com
In OBS, objects are horizontally stored in buckets. It does not provide any hierarchical organization as a file system on a computer. You can create a logical hierarchy by using the object name representing the folder structure. For example, consider a bucket with three objects and the following object names.
- sample1.jpg
- photos/2006/Jan/sample2.jpg
- photos/2006/Feb/sample3.jpg
Although they are not stored as any physical hierarchical organization, you can infer the following logical folder structure from the object name.
- The sample1.jpg object is located at the root level of the bucket.
- The sample2.jpg object is located in the photos/2006/Jan subfolder.
- The sample3.jpg object is located in the photos/2006/Feb subfolder.
Customized Error Document Support
Table 1 lists the subset of the HTTP response code returned by OBS when an error occurs.
HTTP error code |
Description |
---|---|
301 Moved Permanently |
When a user sends a request to an endpoint of OBS, a 301 Moved Permanently response is returned. |
302 Found |
When OBS receives a request for key x that does not end with a slash, it searches for the object whose key name is x. If the object is not found, OBS determines that the request is sent for subfolder x. Then OBS redirects the request by adding a slash at the end of the request, and returns 302 Found. |
304 Not Modified |
OBS users request the If-Modified-Since and If-Unmodified-Since headers to determine whether the requested object is the same as the cached copy stored on the client. If the objects are the same, the website terminal node returns a 304 Not Modified response. |
403 Forbidden |
When the user request is converted into an object that cannot be publicly read, the response of the website terminal node includes 403 Forbidden. The object owner must use bucket policies or ACLs to make the object public and accessible. |
404 Not Found |
The response of the website terminal node contains 404 Not Found due to the following reasons:
You can create customized documents returned for 404 Not Found. Ensure that the document has been uploaded to the bucket configured as a website and the website hosting configuration has been set to use the document. |
500 Service Error |
When an internal server error occurs, the response of the website terminal node contains 500 Service Error. |
503 Service Unavailable |
When OBS determines that you need to reduce the request frequency, the response of the website terminal node contains 503 Service Unavailable. |
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. You 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.
In the static website hosting scenario, anonymous users must be granted access to the hosted static website file. During their access to the hosted file, fees for outbound internet traffic and requests will be incurred.
The following example bucket policy grants each person the permission to access objects in a specified folder. For more information about bucket policies, see Bucket Policies.
{ "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 the read permission to everyone, as shown in the following authorization elements. You can add the authorization element to object ACLs. For details about ACL management, see ACLs.
<Grant> <Grantee> <Canned>Everyone</Canned> </Grantee> <Permission>READ</Permission> </Grant>
Related Functions
Function |
Relationship Description |
Reference |
---|---|---|
CORS |
By default, static websites hosted in an OBS bucket can only respond to access requests from websites in the same domain. You can configure cross-origin resource sharing (CORS) for the bucket so that the static websites can be accessed by cross-domain requests. |
|
URL Validation |
OBS uses URL validation to prevent your websites hosted in an OBS bucket being stolen. OBS verifies URLs based on the referer field in the HTTP header. |
How to Use
You can use OBS Console, APIs, or SDKs to configure static website hosting.
Tool |
Reference |
---|---|
OBS Console |
|
SDKs |
OBS supports software development kits (SDKs) in multiple languages. For details, see the corresponding developer guide on the SDK Overview page. |
API |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.