1. Automate
2. Documentation
3. HTTP accept

HTTP accept

An action block that accepts an incoming HTTP request, download its content.

The fiber will pause until a incoming request has been fully downloaded.

This block should only be used for simple message exchanges coming from a few clients, consider it unreliable and lacking performance for anything else.

After this block the fiber must send a reply using an HTTP response block within 5 seconds, otherwise a failure response (404 or 500) is sent automatically. Multiple blocks, possibly in different flows, can accept requests for the same resource, use this, e.g. with a Fork block, to ensure a block is always ready to process a request. If no block is ready to accept an incoming request then a (404 or 405) failure response is sent, after a few seconds the server will shutdown and stop listening.

The server will bind to the same port on all available addresses on the selected network interfaces when they are available, both IPv4 and IPv6, even when tethering. See IP addresses in system About phone settings, or use the Data network default or Wi-Fi network connected block. Regulars app are not allowed to bind on a port lower than 1024. Carriers usually block requests over the Mobile network, use Cloud message receive block instead.

Use an Keychain alias certificate to enable mTLS/client certificate authentication that will only allow secure connections from clients using the same certificate. Having multiple blocks binding on the same port some with an Keychain alias and others without will have undetermined behaviour.

The URI should be an regular expression that must match the incoming request URI, those are usually relative so do not include a scheme, host nor port (authority), instead just an absolute path, followed by query parameters. So to match a request for a resource that use query parameters ensure to append \\?(.*) to the URI, e.g. /search\\.html\\?(.*), then use the urlDecode function to decode the last capture group of the request URI output variable into a dictionary of parameters.

To process an HTML <form>, save the request preferably to a file if expecting large form inputs, use WWW form or Form-data as content type, then use the urlDecode function to decode the former, or the File multipart extract block extract form inputs and file uploads from the latter.

The save request controls if, and how the request content will be saved. If Save to file, then the path can be set to an existing or new file, or to a directory where the file will be placed with an automatic name. The path to the actual file downloaded is assigned to the request content variable.

Note! Saving large request to variable may cause performance issues since it can be included in the fiber when it’s stored in the internal database.

Input arguments

• Network interface — network interfaces to listen on, default is Loopback, i.e. “localhost”.
• Port — port to listen on, must be above 1024, default is 8443 if an Keychain alias (HTTPS) is used, 8080 otherwise.
• Keychain alias — alias of an certificate used for HTTPS mTLS/client certificate authentication.
• Request URI — a regular expression matching request URI of content to serve, default is /.
• Request method — request method, default is GET.
• Request content type — content MIME type of requests to accept, default is Any.
• Save request — how to save request body content, default is Don’t save.
• Request content path — file or directory path where the downloaded request content will be saved, default is a file in the “Download” directory.

Output variables

• Request URI — variable to assign an array containing the entire matching request URI and any capture groups.
• Request headers — variable to assign a dictionary with the request headers.
• Request content — variable to assign the request content as text, or path to received file.