- Release Notes and Announcements
- Product Introduction
- Purchase Guide (Discontinued)
- Getting Started
- Operation Guide
- Instance Management
- Service Management
- Creating API
- API Creation Overview
- Creating APIs Connecting to the Public URL/IP Backend
- Creating APIs Connecting to the VPC Resource Backend
- Creating APIs Connecting to the SCF Backend
- Creating API for Interconnecting Backend with COS
- Creating APIs Connecting to the Mock Backend
- Creating APIs Connecting to the TSF Backend
- Importing APIs
- API Management
- Calling API
- Release and Access
- Custom Domain Name and Certificate
- Usage Plan
- Backend Upstream
- Verification and Security
- Log Statistics
- Access Monitoring
- API Doc Generator
- Application Management
- Permission Management
- Precautions
- Private IP Ranges and Public VIPs of API Gateway Regions
- Plugin Usage
- Practical Tutorial
- Making Serverless Service Available quickly through API Gateway
- Integrating WAF to API Gateway for Security Protection
- Accessing Resources in IDC via API Gateway Dedicated Instance
- Quick Access to TEM Application via API Gateway
- Integrating ECDN to API Gateway for Acceleration
- API Gateway Providing the Access Capability for TKE
- Migrating from Region A to Region B
- Development Guide
- API Documentation
- Legacy Features
- FAQs
- Service Level Agreement
- Contact Us
- Glossary
- Release Notes and Announcements
- Product Introduction
- Purchase Guide (Discontinued)
- Getting Started
- Operation Guide
- Instance Management
- Service Management
- Creating API
- API Creation Overview
- Creating APIs Connecting to the Public URL/IP Backend
- Creating APIs Connecting to the VPC Resource Backend
- Creating APIs Connecting to the SCF Backend
- Creating API for Interconnecting Backend with COS
- Creating APIs Connecting to the Mock Backend
- Creating APIs Connecting to the TSF Backend
- Importing APIs
- API Management
- Calling API
- Release and Access
- Custom Domain Name and Certificate
- Usage Plan
- Backend Upstream
- Verification and Security
- Log Statistics
- Access Monitoring
- API Doc Generator
- Application Management
- Permission Management
- Precautions
- Private IP Ranges and Public VIPs of API Gateway Regions
- Plugin Usage
- Practical Tutorial
- Making Serverless Service Available quickly through API Gateway
- Integrating WAF to API Gateway for Security Protection
- Accessing Resources in IDC via API Gateway Dedicated Instance
- Quick Access to TEM Application via API Gateway
- Integrating ECDN to API Gateway for Acceleration
- API Gateway Providing the Access Capability for TKE
- Migrating from Region A to Region B
- Development Guide
- API Documentation
- Legacy Features
- FAQs
- Service Level Agreement
- Contact Us
- Glossary
[March 1, 2024] Security Management Notice for the Use of Default Domain Name in API Gateway
Last updated: 2024-01-05 10:07:39
For existing users
For existing users, starting from 00:00:00 on March 1, 2024, in order to ensure the security and stability of the overall service, the API Gateway service will add the following restrictions on the use of the default second-level domain name provided by the platform:
API Gateway services created after 00:00:00 on March 1, 2024:
If you use the default second-level domain name, it does not support previewing when accessed through any browser. Instead, a file is downloaded directly.
If you use the default second-level domain name, there will be no impact when accessed through a non-browser device.
Preview mode will not be supported after March 1, 2024
For API Gateway services created after March 1, 2024, if users access the service through a browser and enter the default domain name, they do not support previewing but directly download the file. The API Gateway will add a Header to the response headers:
Content-Disposition: attachment
If you want to directly preview your services through a browser, please access through a custom domain name. For more information, see Configuring Custom Domain Name.
Services before March 1, 2024 will not be affected
For API Gateway services created before March 1, 2024, the preview of the default domain name will not be affected, but we strongly recommended that you bind a custom domain name and access it as soon as possible.
The platform strictly compllies with related national laws and regulations and does not rule out adding such restrictions to existing services in the future.
How it works
How to download
For the security of all users of the platform, when accessing services using the default domain name provided by the API Gateway, the platform will forcibly add a download response header (Content-Disposition: attachment) in the return.
Note:
When the browser detects Content-Disposition: attachment, it will trigger a forced download.
How to preview
You can customize a subdomain name (for example, detail.example.com) on your own registered domain name (for example, example.com), bind this subdomain name to the API Gateway service, and then use the custom domain name to access it. At this time, the platform will not forcibly add the download response header (Content-Disposition: attachment) in the return.
Note:
At this point, the browser will set it to inline by default. It will directly display the content returned by the backend instead of downloading the file.
For new users
For users who enable the API Gateway service for the first time after 00:00:00 on January 8, 2024, the above restrictions are enforced when the service is enabled.
The advantages of binding a custom domain name
Enable browser preview: To avoid being forced to add a download header, access your services through a custom domain name to preview your service in the browser.
Enhance brand image and professionalism: Bind a custom domain name to the service. The custom domain name is your personalized domain name, which enhances brand image and professionalism and increases user trust.
Prevent domain names from being blocked: Some applications or platforms might block the default domain name of API Gateway. And if you bind a custom domain name, you can ensure that your service can always be accessed normally.
Improve accessibility: Using custom domain names makes it easy for your users to memorize. Compared with using the default domain name, it is more concise and friendly, making it easy to access and share.
Enhance user experience: The use of a custom domain name enhances access speed. Combined with CDN acceleration, it achieves quick content delivery and download, reduces latency and enhances the user experience.
Ensure link persistence: After binding a custom domain name to a service, users can still use the same domain name to access your service even if the service changes subsequently, ensuring link persistence and long-term accessibility.
Yes
No
Was this page helpful?