This topic describes the structural features, invocation descriptions, and limits of HTTP handlers in a custom runtime. This topic also provides examples on how to use an HTTP handler and links to some frequently asked questions.
Background information
Function Compute transparently passes your requests, including methods, paths, queries, request headers, request bodies, and common headers generated by Function Compute to HTTP servers. You can smoothly migrate existing HTTP web applications.
Function invocation
The method that you can use to invoke an HTTP handler is similar to that of a web API operation. You can send a request to invoke an HTTP handler by using cURL, Postman, or a browser. When you use a browser to access an HTTP trigger, a function may be downloaded in a forceful manner. For more information about how to resolve this issue, see When I use a web browser to access a function with an HTTP trigger, why do I need to download the response?
Header | Description |
(Optional) x-fc-base-path | If you do not specify a custom domain name, |
(Optional) x-fc-status | This header behaves in a similar manner to a header in an event function. This is applicable to HTTP functions that are not migrated to Function Compute but created by calling a web API operation. You can include the x-fc-status field in response headers to report to Function Compute whether the local function is successfully invoked.
Note We recommend that you specify the StatusCode and x-fc-status fields in the HTTP response. |
Usage notes
Only one HTTP trigger can be created for an HTTP function in each version or alias of a service. For more information, see Manage versions and Manage aliases.
Limits on HTTP requests
Request headers do not support custom fields that start with x-fc- or the following fields:
connection
keep-alive
The system returns the
400status code andInvalidArgumenterror code if a request exceeds one of the following limits:Headers size: The total size of all keys and values in headers cannot exceed 8 KB.
Path size: The total size of the path, including all query parameters, cannot exceed 4 KB.
Body size: The total size of the body of a synchronous invocation request cannot exceed 32 MB. The total size of the body of an asynchronous invocation request cannot exceed 128 KB.
HTTP response limits
Response headers do not support custom fields that start with x-fc- or the following fields:
connection
content-length
date
keep-alive
server
content-disposition:attachment
NoteFor security reasons, if you use the default domain name aliyuncs.com of Function Compute, the server forcibly adds the content-disposition: attachment field to response headers. This field makes the returned results to be downloaded as an attachment in a browser. To remove this limit, you must specify a custom domain name. For more information, see Configure a custom domain name.
If a response exceeds one of the following limits, the system returns status code
502and errorBadResponse.Headers size: The total size of all keys and values in headers cannot exceed 8 KB.
Others
You can bind custom domain names to map different HTTP paths for HTTP functions. For more information, see Configure a custom domain name. You can also use API Gateway to implement similar features by setting the backend service type to HTTP and specifying the HTTP function path as the backend service address. For more information, see Use Function Compute as the backend service of an API operation.
Examples for other programming languages
You can use Serverless Devs to migrate your applications to Function Compute with a few clicks. The following example shows how to use Serverless Devs to deploy and invoke a function in an efficient manner. You can modify the sample code based on your business requirements.