Functions are blocks of code that run on demand without the need to manage any infrastructure. Develop on your local machine, test your code from the command line (using doctl), then deploy to a production namespace or App Platform — no servers required.
The web event (the http key in the event parameter passed to your handler function) contains the request’s HTTP headers under the headers key.
The following headers are always present as keys under headers:
accept: The types of content the client is able to use. This can be a single MIME type or a list of multiple types. Common values are text/html and application/json.
Multiple accept headers may be used instead of a single header with a list. The values of multiple headers are merged into a single comma-seperated list. More info: MDN: Accept
accept-encoding: The types of content encoding the client can use, such as gzip or deflate. For Functions, this is always gzip. More info: MDN: Accept-Encoding
content-type: The MIME type of the data being sent in the request body. For Functions, this is often application/json or multipart/form-data. More info: MDN: Content-Type
user-agent: A string identifying the web browser, library, or other HTTP client making the request. More info: MDN: User-Agent
x-forwarded-for: The IP address of the client. Can be IPv4 or IPv6. More info: MDN: X-Forwarded-For
x-forwarded-proto: The protocol the client used to connect. Either http or https. More info: MDN: X-Forwarded-Proto
x-request-id: A unique ID for the function invocation used by internal DigitalOcean monitoring systems.
The requesting client or library can add additional headers to the request. The header name is always converted to lowercase and used as a key in the headers dictionary. The header’s value is always a string.
Additionally, the Functions service may add headers to requests and responses that are not documented in the preceding section. These headers are used internally by Functions infrastructure and may change at any time.