Function Compute:Overview

Usage notes

• If your HTTP trigger is set to anonymous, that is, its Authentication Method is set to No Authentication, no identity verification is required, allowing anyone to invoke your function via HTTP requests, which poses serious security risks. To prevent such risks, you can configure signature authentication for your HTTP trigger and verify the identity of the requester via the Authorization header of an HTTP request. For more information, see Configure signature authentication for HTTP triggers.

• According to China's 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. If you attempt to do so, a 400 error code is returned. 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

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 intended only for testing purposes. Their stability cannot be guaranteed, which may impact your online services. Therefore, we recommend that you do not use built-in domain names for any external online services.

  Note

  Public-facing websites can only use domain names that have obtained ICP filings. You can configure a filed custom domain name, bind it to your function, and then use that domain to provide website services externally. For more information, see Configure custom domain names.

Limits on HTTP(S)

• 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 a 400 status code and an 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 parameters, 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

  • Response headers do not support custom fields that start with x-fc- or the following fields:

    • 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 a content-disposition: attachment response header, which is used to download the returned results from the browser as attachments. To remove this restriction, use a custom domain name. For more information, see Configure custom domain names.

  • If a response exceeds one of the following limits, the system returns a 502 code and a 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: When you bind a custom domain name, you can configure the mapping between paths and functions. This way, requests from different paths can trigger different functions. For more information, see Configure custom domain names.

• API Gateway triggers: You can use API Gateway with Function Compute set as the backend service to implement similar features. For more information, see Function Compute.

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

• HTTP triggers are easier for developers to learn, use, and debug. This 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.

• HTTP triggers allow you to use familiar HTTP test tools to test the features and performance of Function Compute.

• You can integrate HTTP triggers with other services that support webhooks with ease, such as CDN and Simple Message Queue (formerly MNS).

Invocation methods

Synchronous invocation

During a synchronous invocation, the function processes the request and then returns the result. By default, an HTTP trigger invokes a function in this synchronous mode. For more information, see Synchronous invocations.

Asynchronous invocation

During an asynchronous invocation, Function Compute persists the request and immediately returns a response without waiting for the execution to complete.

• Asynchronous invocation: You can use an HTTP trigger to invoke a function in asynchronous mode by adding the "X-Fc-Invocation-Type":"Async" request header.

• Asynchronous task: After you enable the asynchronous task feature for your function, you can add the "X-Fc-Async-Task-Id":"g6u*****iyvhd3jk8s6bhj0hh" request header to configure the invocation ID for the asynchronous task.

For more information about request headers, see InvokeFunction.

After a successful asynchronous invocation, Function Compute returns a 202 code, which indicates that the request was received successfully. In addition, Function Compute returns the request ID based on the request headers. The format of the ID is "X-Fc-Request-Id": "80bf7****281713e1".

Authentication

You can configure authentication for HTTP triggers, requiring external requests to pass authentication before your functions process them.

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. During an invocation, the AccessKey IDs, AccessKey secrets, and signature are passed to Function Compute for authentication. For more information, see Configure signature authentication for HTTP triggers.

This authentication method is highly secure, but it requires clients to implement the signature algorithm, which can be costly. Additionally, the AccessKey IDs and AccessKey secrets must be stored on clients, increasing the risk of leakage. Using Security Token Service (STS) tokens can mitigate this issue, but this introduces some architectural complexity.

JWT authentication

JWT is a widely used and secure method for API authorization and access, particularly suitable for low-security client scenarios like JavaScript or web frontends. For more information, see Configure JWT authentication for an HTTP trigger.

CORS request processing

By default, Function Compute allows you to invoke functions across origins. It also lets you write code to handle CORS requests.

Simple requests

A preflight request is not required for a simple request. You can configure a header that starts with Access-Control-Allow-* in your function code to implement access control with ease. For simple requests, Function Compute supports the following custom headers: Access-Control-Allow-Origin, Access-Control-Allow-Headers, Access-Control-Request-Method, and Access-Control-Max-Age.

If you do not configure custom headers, Function Compute fills the following response headers:

• 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.

Non-simple requests

A preflight request is sent before a non-simple request is sent: The browser sends a preflight request by using the OPTIONS method, and then initiates the actual request to invoke a function. The rules to initiate a non-simple request are the same as the rules to initiate a simple request. If you want to specify custom responses for a preflight request, you must add the OPTIONS method to an HTTP trigger and process the OPTIONS request in your function code. Specifically, you can configure headers that start with Access-Control-Allow-* to control how your function behaves with cross-origin requests.

For preflight requests, Function Compute supports the following custom headers: Access-Control-Allow-Origin, Access-Control-Allow-Headers, Access-Control-Allow-Methods, and Access-Control-Max-Age.

In this example, a built-in Node.js runtime is used to describe how to process preflight requests in the function code:

exports.handler =  (event, context,callback) => {
      console.log('hello world');
      const method = JSON.parse(event).requestContext.http.method;
      if (method === 'OPTIONS') {
          // Set response headers to handle the preflight request.
          const fcResponse = {
            'statusCode': 204,
            'headers': {
              'Access-Control-Allow-Origin': 'http://www.fc.com',
              'Access-Control-Allow-Methods': 'POST',
              'Access-Control-Allow-Headers': 'Content-Type, Authorization',
              'Access-Control-Max-Age':'3600'
            },
            'body': 'hello world'
        };
        callback(null, fcResponse);
      } else {
        callback(null, {
            'statusCode': 500,
            'body': 'hello world'
        });
      }
    };

FAQ