All Products
Search
Document Center

Function Compute:Overview

Last Updated:Nov 07, 2024

An HTTP trigger allows you to invoke a function by using HTTP requests. HTTP triggers can be used in scenarios such as rapid development of web services. Before you use an HTTP trigger, make sure that you are familiar with limits on HTTP triggers and limits on protocols supported by HTTP triggers, including the HTTP/HTTPS, WebSocket, and gRPC protocols, to prevent function errors caused by limit exceeding. This topic describes the limits, invocation methods, and authentication methods of HTTP triggers, as well as handling of cross-origin resource sharing (CORS) requests.

Usage notes

  • If you use an anonymous HTTP trigger whose Authentication Method is set to No Authentication, no identity authentication is required. In this case, anyone can send an HTTP request to invoke your function. This may lead to URL leakage. To avoid URL leakage, you can use the Authorization field of a request header to check the validity of a request. For more information, see Configure signature authentication for HTTP triggers.

  • According to national cybersecurity regulations, starting from June 10, 2024, newly created HTTP triggers cannot be used to download Android Package Kit (APK) files (mime type: application/vnd.android.package-archive) from public endpoints. A 400 error is reported if you attempt to download an APK file from an HTTP public endpoint. For more information, see Why does a public endpoint of an HTTP trigger fail to return an .apk file?

  • Be mindful of the virtual IP address (VIP) rotation mechanism.

    To enhance system resilience and service stability, Function Compute implements a VIP rotation mechanism. Specifically, VIPs that correspond to public and internal endpoints of HTTP triggers in Function Compute are rotated from time to time. The VIP rotation mechanism constitutes an integral part of the infrastructure robustness.

    Therefore, hard coding of VIPs may cause service interruptions. We recommend that you use custom domain names to ensure service robustness. Note that failures caused by improper use of VIPs are not covered by the compensation scope of Function Compute. Review your configurations and make necessary adjustments if VIPs are improperly used.

    You can use a custom domain name with a CNAME to access Function Compute. For more information, see Configure custom domain names.

Limits

Before you configure and use an HTTP trigger, make sure that you are familiar with the limits on HTTP triggers and the limits on protocols supported by HTTP triggers, including the HTTP/HTTPS, WebSocket, and gRPC protocols.

Limits on triggers

  • For each version or alias of a function, you can create only one HTTP trigger. For more information, see Manage versions and Manage aliases.

  • By default, the built-in domain names provided by HTTP triggers are only for tests. The stability of the built-in domain names is not guaranteed and may affect your online services. We recommend that you do not use built-in domain names for external online services.

    Note

    Website services can be provided only by using domain names for which ICP filings are obtained. You can configure a custom domain name, bind the domain name to your function, and then use the domain name to provide services. For more information, see Configure a custom domain name.

Limits on HTTP/HTTPS

Note

You can use the following methods to trigger functions: GET, POST, PUT, DELETE, HEAD, PATCH, and OPTIONS. The HTTP and HTTPS protocols are suitable for simple request-response scenarios. For more information, see Configure and use an HTTP trigger.

  • Limits on HTTP requests

    • You cannot create a request header that starts with x-fc- or the following request headers:

      • connection

      • keep-alive

    • The system returns the 400 status code and the InvalidArgument error 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 a path, including all query params, cannot exceed 8 KB.

      • Body size: The total body size of a synchronous invocation request cannot exceed 32 MB. The total body size of an asynchronous invocation request cannot exceed 128 KB.

  • Limits on HTTP responses

    • You cannot use a custom response header that starts with x-fc- or the following custom response headers:

      • connection

      • content-length

      • date

      • keep-alive

      • server

      • upgrade

      • content-disposition:attachment

        Note

        For security reasons, if you use the default domain name aliyuncs.com of Function Compute, the server forcibly adds the content-disposition: attachment response header, which is used to download the returned results from the browser as attachments. If you want to remove this restriction, you can use 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 the 502 code and the BadResponse error:

      • Headers size: The total size of all keys and values in headers cannot exceed 8 KB.

Benefits:

Both HTTP triggers and API Gateway triggers can be used to create web applications. The following items describe each type of triggers:

  • HTTP triggers: You can bind a custom domain name to map different HTTP access paths to HTTP functions. For more information, see Configure a custom domain name.

  • API Gateway triggers: You can also use API Gateway triggers. In this case, set Backend Service Type to Function Compute 3.0, set Function Type to HTTP Function, and then set the backend service address to implement similar features. For more information, see Function Compute.

Compared with API Gateway triggers, HTTP triggers deliver the following benefits:

  • HTTP triggers can be easily learned and used by developers. This simplifies the debugging process and helps developers quickly build web applications and APIs by using Function Compute.

  • You can use HTTP triggers to optimize request processing. HTTP triggers support efficient request and response formats. You do not need to encode or decode requests to the JSON format. This helps deliver better performance.

  • You can use an HTTP test tool with which you are familiar to test features and performance in Function Compute.

  • You can connect HTTP triggers to other services that support webhooks with ease, such as Alibaba Cloud CDN and Message Service (MNS).

Invocation methods

Functions can be invoked in either synchronous or asynchronous modes. During a synchronous invocation, results are returned after an event is processed by a function. During an asynchronous invocation, Function Compute persists the request and immediately returns a response without waiting for the execution of the request to complete.

Synchronous invocation

By default, an HTTP trigger invokes a function in synchronous mode. For more information, see Synchronous invocation.

Asynchronous invocation

You can use an HTTP trigger to invoke a function in asynchronous mode at the request level by adding the "X-Fc-Invocation-Type":"Async" request header. For more information about request headers, see InvokeFunction.

If an asynchronous invocation is successful, Function Compute returns the 202 code, which indicates that the request is received. In addition, Function Compute returns the request ID by using a request header. The format of the ID is "X-Fc-Request-Id": "80bf7****281713e1".

Note

If the status code returned from Function Compute is not 202, the asynchronous invocation fails. For more information about the causes of invocation failures, see Configure a retry mechanism.

In specific scenarios, you may want Function Compute to defer the execution after you submit an asynchronous invocation request. If you want Function Compute to defer an execution, you can add the x-fc-async-delay HTTP request header to your code. The value range of the header is (0,3600). Unit: seconds. Function Compute invokes the function after the period specified for x-fc-async-delay elapses. For more information, see the Deferred invocation of a function section of the "Overview" topic.

References

  • For more information about asynchronous invocations, see Overview.

  • For more information about asynchronous tasks, see Overview.

Authentication

You can configure authentication for HTTP triggers. After you configure authentication for an HTTP trigger, external requests must pass the authentication before functions can process the requests.

Signature authentication and JSON Web Token (JWT) authentication can be configured for HTTP triggers.

Signature authentication

If a signature authentication policy is configured for an HTTP trigger, requests must be signed by using the assigned AccessKey IDs and AccessKey secrets. The AccessKey IDs and AccessKey secrets are passed to Function Compute for authentication. For more information, see Configure signature authentication for HTTP triggers.

This authentication method is highly secure, but the signature algorithm must be implemented on clients, which is costly. In addition, AccessKey IDs and AccessKey secrets must be stored on clients. As a result, AccessKey IDs and AccessKey secrets may be leaked. You can use Security Token Service (STS) tokens to address this issue. However, certain architectural complexity is introduced.

JWT authentication

JWT is a popular and secure mechanism for API authorization and access. It is suitable for low-security client scenarios such as JavaScript or web frontends. For more information, see Configure JWT authentication for an HTTP trigger.

CORS request processing

By default, Function Compute allows across-origin invocations. The following items describe the default configurations of response headers in Function Compute.

  • Access-Control-Allow-Origin: the origin header of a request.

  • Access-Control-Allow-Credentials: whether to allow credentials. The default value is true.

  • Access-Control-Expose-Headers: custom headers of Function Compute.

FAQ

Do I need to configure listening ports?

When you create a function, you must configure a listening port only if you select Web Function.

What do I do if a function requires a long period of time to invoke?

What do I do if the 499 status code is returned to a client and the client cancels requests?

  • If the 499 status code is returned on a client, function instances are restarted. You can configure health checks for function instances to prevent instances from being restarted. For more information, see Why is a function instance restarted after the 499 error occurs on a client?

  • If function invocation times out on a client, you can move time-consuming logic to the code of a new function. Then, invoke the new functions in asynchronous mode. You can also use the asynchronous invocation mode when you initiate invocations on a client.

How do I update the configurations of a running function?

  • The function configurations are updated only after the function execution completes. After you update the configurations of a function, the previous configurations still take effect for requests that are being executed. The updated configurations take effect for subsequent requests.

  • You can delete the current function and create another function whose configurations meet your business requirements.