An HTTP trigger triggers the execution of a specific function by sending an HTTP request. HTTP triggers can be used in scenarios such as the fast construction of web services. The supported HTTP request methods include HEAD, POST, PUT, GET, and DELETE. This topic describes the benefits and limits of HTTP triggers, and handlers of functions with HTTP triggers.
Benefits
Both HTTP triggers and API Gateway triggers can be used to create web applications. Compared with API Gateway triggers, HTTP triggers have the following benefits:
- HTTP triggers reduce the training costs and simplify the debugging processes for developers, and help developers efficiently build web services and APIs by using Function Compute.
- You can use HTTP test tools with which you are familiar to test the functionality and performance of HTTP triggers in Function Compute.
- Request processing is streamlined. HTTP triggers support more efficient request and response formats. You do not need to encode or decode the request to the JSON format and better performance is achieved.
- You can connect HTTP triggers to other services that support webhooks with ease, such as Content Delivery Network (CDN) back-to-origin and Message Service (MNS).
Limits
- After an HTTP trigger is set for a function, other types of triggers cannot be set for this function.
- Only one HTTP trigger can be created for each function.
- If version management is enabled for a function, only one HTTP trigger can be created for each version or alias of the function. In other words, one HTTP trigger can be created for one version or one alias of a function. For more information about versions and aliases, see Introduction to versions.
- The following fields in a request header and request headers that start with x-fc- cannot be customized:
- accept-encoding
- connection
- keep-alive
- proxy-authorization
- te
- trailer
- transfer-encoding
- The following fields in a response header and response headers that start with x-fc- cannot be customized:
- connection
- content-length
- content-encoding
- date
- keep-alive
- proxy-authenticate
- server
- trailer
- transfer-encoding
- upgrade
- content-disposition:attachmentNote For security, when the default aliyuncs.com domain name of Function Compute is used, the server forcibly adds the content-disposition: attachment field to the response header. This field is used to download the returned result in the browser as an attachment. To remove this limit, you must set a custom domain name. For more information, see t1881050.html#multiTask2940.
- Limits on HTTP requests
If a request exceeds one of the following limits, the system returns status code
400
and error codeInvalidArgument
.- Header size: The total size of all keys and values in the headers cannot exceed 4 KB.
- Path size: The total size of the path, including all of the query parameters, cannot exceed 4 KB.
- Body size: The total size of the HTTP request body cannot exceed 6 MB.
- Limits on HTTP responses
If a response exceeds one of the following limits, the system returns status code
502
and error codeBadResponse
.- Header size: The total size of all keys and values in the headers cannot exceed 4 KB.
- Body size: The total size of the HTTP response body cannot exceed 6 MB.
- Other instructions
You can map different HTTP paths for HTTP functions by binding a custom domain name. For more information, see t1881050.html#multiTask2940. You can also use API Gateway, set the backend service type to HTTP, and configure the HTTP function path as the backend service address to implement similar features. For more information, see Use Function Compute as the backend service of an API operation.
Handlers of functions with HTTP triggers
- Node.js
- Python