You can configure a bucket to host a static website in the COS Console and access the static website at the bucket's access domain name. For more information on static websites, see Static Website Hosting.
- To use buckets to host static websites, you first need to set the access permission of buckets to Public Read/Private Write.
- For the static website configuration to take effect, you should use a static website domain name instead of a COS default domain name to access the COS origin server.
You have created a bucket. For more information, see Creating a Bucket.
Log in to the COS Console and then select the Bucket List in the left pane. Click the bucket to host static websites to enter the bucket details page.
Click Permission Management > Bucket ACL(Access Control List) on the left sidebar, select Public Read/Private Write for Public Permissions, and save.
Click Basic Configuration on the left, and find the Static Website configuration item. Click Edit, toggle on the Status switch, and set the static website configuration items as shown below:
Mandatory HTTPS (Optional): After mandatory HTTPS is enabled, when a user accesses your static website, the access node of the static website will be forced enabled by using HTTPS protocol.
Index Document (required): An index document (i.e., the homepage of the static website) is a page returned when the root directory or any subdirectory of a website is requested, which is usually named index.html.
If folders are created in the bucket, the index document needs to be added at each folder level.
Error Document (optional): An error document is a page returned after an error occurs in accessing a static website. This configuration item allows you to define an error document. When the static website cannot respond to end user requests, the specified custom error page will be returned. For example, when an HTTP error occurs in accessing, if an error document named error.html is configured, the error.html page will be returned for easy troubleshooting. However, if it is not configured, the default error message will be returned.
Only a file in the bucket root directory can be configured as an error document. A file that is recognizable by browsers should be used, such as an
.htmfile. Most browsers will display "inaccessible" or "access request denied" if an unrecognizable file such as a
.zipfile is used.
Redirection Rules (Optional): With redirection rules, you can redirect requests based on specific file paths, prefixes in requests, or response codes.
For example, if a file in a bucket is deleted or renamed, you can add a redirection rule to redirect requests to other files.
4xxerror codes (such as 404). You can customize the error page. If a corresponding HTTP error is triggered, you can provide guidelines for your users in the error page.
After configuration, click Save.
Currently, the new and legacy consoles have different bucket domain name formats. Taking the Guangzhou region as an example, the bucket region name is referred to as ap-guangzhou in the new console, but it is cosgz in the legacy console. For more information on domain names, see Regions and Endpoints.
Due to the differences in bucket domain name formats, when you use the static website feature, the access nodes for legacy and new versions of static website are also different. Take a bucket in the Chengdu region as an example:
If you have configured the static website feature in the legacy console, after upgrading to the new console, you can view it there, as shown below. To do so, simply click Click to Load in the Historical Versions of Static Website section.
Now you can see the legacy static website configuration.
It should be noted that the legacy static website configuration can only be viewed but not edited. To experience the richer and more stable features of the new console, it is recommended that you reconfigure your static website domain name in the new console. Before reconfiguring, you need to take into account the following:
In addition to the domain name differences, the APIs called by the new and legacy consoles are different too. It is recommended that you use the new version of console, APIs, tools, and SDKs for a richer experience and more stable features. The APIs of object or bucket operations called in the new COS Console are XML APIs, while those in the legacy console are JSON APIs. For more information on the API differences, see API and SDK.