You use HTTP functions when you want to invoke your function via an HTTP(s) request. To allow for HTTP semantics, HTTP function signatures accept HTTP-specific arguments.
Sample usage
The example below shows how to process an HTTP POST request containing a
name
parameter:
Node.js
Python
Go
Java
C#
Ruby
The following command shows how to call the function and pass it a parameter
using curl
:
curl -X POST HTTP_TRIGGER_ENDPOINT -H "Content-Type:application/json" -d '{"name":"Jane"}'
where HTTP_TRIGGER_ENDPOINT
is the URL for the
function, obtained when the function is deployed. For more information, see
HTTP Triggers.
HTTP frameworks
To handle HTTP, Cloud Functions uses a particular HTTP framework in each runtime:
Runtime | HTTP framework |
---|---|
Node.js (8, 10 & 12) | Express 4.17.1 |
Python | Flask 1.0.2 |
Go | Standard
http.HandlerFunc
interface
|
Java | Functions Framework Java API |
.NET | Functions Framework for .NET |
Ruby | Functions Framework for Ruby |
Parsing HTTP requests
The example below shows how to read HTTP requests in various formats:Node.js
In Node.js, the body of the request is automatically parsed based on the
content-type
header and made available via your HTTP function's arguments.
Python
Go
Java
C#
Ruby
Handling CORS requests
Cross-Origin Resource Sharing (CORS) is a way to let applications running on one
domain access content from another domain, for example, letting yourdomain.com
make requests to region-project.cloudfunctions.net/yourfunction
.
If CORS isn't set up properly, you're likely to get errors that look like this:
XMLHttpRequest cannot load https://region-project.cloudfunctions.net/function. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://yourdomain.com' is therefore not allowed access.
CORS consists of two requests:
- A preflight
OPTIONS
request. - A main request that follows the
OPTIONS
request.
The preflight request contains headers indicating which method
(Access-Control-Request-Method
) and which additional headers
(Access-Control-Request-Headers
) will be sent in the main request, as well
as the origin of the main request (Origin
).
To handle a preflight request, you must set the appropriate
Access-Control-Allow-*
headers to match the requests you want to accept:
Node.js
Python
Go
Java
C#
Ruby
Alternatively, you can use a third-party library to handle CORS for you.
Authentication and CORS
If you plan to send a request with an Authorization
header, you must:
- Add the
Authorization
header toAccess-Control-Allow-Headers
. - Set the
Access-Control-Allow-Credentials
header totrue
. - Set a specific origin in
Access-Control-Allow-Origin
(wildcards are not accepted).
Node.js
Python
Go
Java
Hosting on the same domain
Instead of implementing CORS, you could instead host your website and your functions on the same domain. Since requests would now come from the same origin, CORS won't be enforced. This simplifies your code considerably.
The easiest way to do this is to integrate Firebase Hosting with Google Cloud Functions.
Using Cloud Endpoints to handle CORS
You can deploy a Cloud Endpoints proxy and enable CORS.
If you want authentication capabilities, you can also enable Google ID token validation, which will validate authentication tokens.
Handling HTTP methods
HTTP functions accept all HTTP methods. The following sample shows how to
perform different actions based on the HTTP method received (for example, GET
and PUT
):
Node.js
Python
Go
Java
C#
Ruby
Handling Content Types
For Node.js, Cloud Functions parses request body content types of
application/json
and application/x-www-form-urlencoded
as shown above. Plain
text content types (text/plain
) are passed through as strings using UTF-8 as a
default encoding (or a custom encoding provided in the content-type
header).
Other content types can be accessed by inspecting your HTTP function's argument. Methods for doing this vary by language.
The example below handles a request with a content type of text/xml
:
Node.js
TherawBody
property contains the unparsed bytes of the request body.
Python
Go
Multipart Data
The following example shows how to process data with a multipart/form-data
content type. Depending on your chosen language, you may need to use a
parsing library.
Node.js
Python
Go
Java
C#
Ruby
Uploading Files via Cloud Storage
A common use case for Cloud Functions is file processing. For larger files or those that require persistent storage beyond the scope of a single request, you can use Cloud Storage as an entry point for your file uploads. To accomplish this, you must generate a Signed URL, which provides temporary write access to a Cloud Storage bucket.
If you're using Cloud Functions directly, generate a signed URL using the appropriate Cloud Storage client library.Uploading files to a Cloud Function using Cloud Storage is a three step process:
Clients call a Cloud Function directly to retrieve a signed URL.
Clients then send file data to the signed URL via an HTTP PUT request.
A second Cloud Function is triggered by the mutation in the storage bucket to further process the file.
You can see an example below of using the Cloud Storage client library to generate a signed URL.
Cloud Functions have a "default application credential" which typically does not
include the iam.serviceAccounts.signBlob
permission. To allow this, you'll
need to first make sure that your function's service account has the appropriate
role. You can achieve this using either the Cloud Console
or the gcloud
command-line tool:
console
To make sure that your function's service account has the appropriate role, you can directly modify the IAM roles for an account:
- Go to the Google Cloud Console:
- Select the appropriate account, and choose Editor > Service Accounts > Service Account Token Creator.
gcloud
To make sure that your function's service account has the appropriate
role, run the following command. The pre-defined serviceAccountTokenCreator
role has the iam.serviceAccounts.signBlob
permission you need:
gcloud projects add-iam-policy-binding YOUR_PROJECT \ --member serviceAccount:YOUR_SERVICE_ACCOUNT --role roles/iam.serviceAccountTokenCreator
You can determine the service account used by your functions using either the Cloud Console
or the gcloud
command-line tool:
console
To determine the service account used by your functions using Cloud Console:
Go to the Google Cloud Console:
Select the function you want to inspect from the list.
You can see the service account on the details page for the function.
gcloud
To determine the service account used by your functions, run the following command and look for the serviceAccountEmail
property:
gcloud beta functions describe YOUR_FUNCTION_NAME
Here's an example of generating a signed URL:
Node.js
Python
Go
Java
C#
When the client uploads a file to the signed URL, you can trigger a second function from this mutation if you want to take further action on the upload. See the Cloud Storage Tutorial for more information on triggering a Cloud Function upon changes to a Cloud Storage bucket.