Skip to main content

HTTP gateways

Advanced
Tutorial

Overview​

The ICP HTTP gateway protocol enables conventional HTTP clients to interact with the ICP network. HTTP gateways run adjacent to ICP and provide a connection used by software such as web browsers to send and receive standard HTTP requests and responses, including static assets, such as HTML, JavaScript, images, or videos. The HTTP gateway makes this workflow possible by translating standard HTTP requests into API canister calls that ICP canisters can understand and vice versa for HTTP responses.

There are several HTTP gateway instances maintained for ICP, but it should be noted that an HTTP gateway is a centralized component that could become compromised, creating a threat for users receiving HTTP content.

DFINITY exclusively controls the HTTP gateways that serve canisters on ic0.app and icp0.io. Developers can then also configure their own custom domains to point at the DFINITY controlled HTTP gateways.

Alternatively, developers can run their own HTTP gateways on their custom domains instead of using the DFINITY controlled gateways, but this is not well supported yet.

For a more secure solution, it is possible to run your own HTTP gateway instance locally.

Terminology​

  • Request: A message sent to a server or endpoint.

  • Client: A service that is able to send an HTTP formatted request and receive a response from a server.

  • Gateway: Enables the transfer of inbound and outbound messages.

HTTP request lifecycle​

On ICP, an HTTP request goes through the following lifecycle:

  1. An HTTP client makes an outbound request.

  2. The HTTP gateway intercepts the request and resolves the canister ID of the request's destination.

  3. The request is encoded with Candid and sent in a query call to the destination canister's http_request method.

  4. This request is sent to an ICP API boundary node, which will then forward the request to a replica node on the relevant subnet.

  5. The canister receives and processes the request, then returns the response.

  6. The HTTP gateway decodes the Candid encoding on the response.

  7. If the canister requests it, the gateway sends the request again via an update call to the canister's http_request_update method. The update call goes through consensus on the subnet.

  8. If the response size exceeds the maximum response size, the HTTP gateway fetches additional response body data through query calls.

  9. The HTTP gateway validates the response's certificate, if applicable.

  10. The HTTP gateway returns the decoded response to the HTTP client.

Additional details can be found in the HTTP gateway specification.

Running a local HTTP gateway​

To run your own local HTTP gateway, a proof-of-concept implementation can be used that enables a secure end-to-end connection with canisters deployed on ICP.

This implementation features:

  • Translation between HTTP asset requests and ICP API calls.

  • Detects ICP domains from principals and custom domain records.

  • Terminates TLS connections locally.

  • Bypasses remote gateway denylists.

  • Resolves crypto domains.

Installation​

You can download the pre-built installation package for your operating system.

Once installed, you will have the option to start or stop the IC HTTP proxy service. Start the service to begin using it. Once the proxy is running, it will handle all traffic on your computer. Any traffic that's not meant for the ICP mainnet will pass through the gateway, and traffic that is meant for ICP will be intercepted by the proxy. The proxy will log traffic in the file $HOME/Library/Preferences/dfinity/ichttpproxy/ic-http-proxy-proxy.log on macOS machines, or in the tmp directory on Windows machines.

For example, make the following curl request to the NNS:

curl -v https://nns.ic0.app

This will result in a log entry of:

{"level":30, "time": "2024-06-17T13:46:40.947Z","pid":43956,"hostname":"JessieMgeonsMBP.attlocal.net","name":"IC HTTP Proxy Server","msg":"Proxying web3 request for nns.ic0.app:443"}

Resources​