Validating HTTP/3 Protocol Support on a Local Site

In the domain of web development, the implementation of HTTP/3 can contribute significantly to the enhanced performance characteristics of a site. For developers who have integrated HTTP/3 into their local environments, it is important to validate that browsers are leveraging the protocol effectively. Below, we show 3 options for verifying HTTP/3 functionality.

Table of Contents

• Understanding Browser Protocol Selection
• Method 1: Verification Using Google Chrome
• Method 2: Verification Using Mozilla Firefox
• Method 3: Verification Using Curl
• Conclusion
• Bonus: verifying HTTP/3 support in CI/CD pipelines (e.g. GitHub Actions)

Understanding Browser Protocol Selection

Modern browsers do not inherently initiate connections using HTTP/3 due to its relatively recent introduction and current support status. Instead, they commence with established protocols such as HTTP/1.1 or HTTP/2. The server must signal HTTP/3 availability via the Alt-Svc header in HTTP responses. This indication allows browsers to switch to HTTP/3 for subsequent requests, caching this information for future connections.

For more information on how and why browsers do or do not connect via HTTP/3, refer to HTTP/3: Practical Deployment Options - alt-svc header.

Assuming the successful deployment of a local site with HTTP/3, use the following methods to verify its use:

Method 1: Verification Using Google Chrome

To confirm that Google Chrome utilizes HTTP/3, you can start the browser with a command-line argument that forces the use of this protocol, as follows:

google-chrome --origin-to-force-quic-on=app.localhost:443

Make sure to replace app.localhost with your site's hostname.

Ensure that all instances of Chrome are closed before this operation to apply the command-line argument correctly.

To verify the protocol, open the DevTools (F12), navigate to the Network tab and make sure that the Protocol column is enabled (right click on the table header and check "Protocol"). The Protocol column should display h3 or something alike if it was served via HTTP/3.

Method 2: Verification Using Mozilla Firefox

Mozilla Firefox may switch to HTTP/3 after several page refreshes. If this does not occur, restarting the browser and repeating the refresh process can prompt the desired switch to HTTP/3.

Method 3: Verification Using Curl

Curl, when equipped with the --http3-only flag, can exclusively test for HTTP/3 connections. Note that not all versions of Curl support HTTP/3, necessitating alternative solutions such as the ymuski/curl-http3 Docker image.

We assume that the local site is hosted at https://app.localhost; ensure to replace this with your site's hostname.

Initially, you might try to connect to your site using the following command with the --http3 and --insecure flags (the --insecure flag is used to bypass certificate validation in development scenarios):

docker run ymuski/curl-http3 curl --insecure --http3-only https://app.localhost

However, this will result in the following error:

curl: (7) QUIC: connection to 127.0.0.1 port 443 refused

The problem is that Docker, by default, creates its own virtual network within the host machine. This means that the containerized Curl command cannot resolve the given URL (https://app.localhost), since the app probably runs on your own machine and not inside the container.

This issue can be addressed by explicitly instructing Docker to use the host network via the --network="host" flag:

docker run --network="host" ymuski/curl-http3 curl --insecure --http3-only https://app.localhost

For header inspection and confirmation of the protocol in use, appending the --head flag to the Curl command will display the necessary information:

$ docker run --network="host" ymuski/curl-http3 curl --insecure --head --http3-only https://app.localhost
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   336    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/3 200
(...)

The HTTP/3 200 output confirms that the HTTP/3 protocol is in use.

Conclusion

Verifying HTTP/3 support in a local development setting requires specific techniques, each pertinent to the tools and browsers in use.

By employing the methods outlined above, developers can confirm the operational status of HTTP/3 on their local sites, ensuring that the protocol's advantages are realized during development. This is a step forward in optimizing web performance and adhering to contemporary internet standards.

Bonus: verifying HTTP/3 support in CI/CD pipelines (e.g. GitHub Actions)

To verify HTTP/3 support in your CI/CD pipeline, such as GitHub Actions, you can use the Curl method described earlier. The idea is to start your local site in the background and then execute the Curl command against it.

Here's an example GitHub Actions Workflow using Docker Compose:

name: Test
on:
  push:
    branches: [main]
jobs:
  http3-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Start containers
        run: docker-compose -f "docker-compose.yml" up -d
      - name: Test HTTP/3
        # Make sure to replace `app.localhost` with your site's hostname.
        run: docker run --network="host" ymuski/curl-http3 curl --insecure --head --http3-only --retry 3 --retry-all-errors --fail https://app.localhost
      - name: Stop containers
        if: always()
        run: docker-compose -f "docker-compose.yml" down

This workflow checks out the code, starts the services using Docker Compose, tests the HTTP/3 protocol support, and finally tears down the services.

You can find the full example in the following GitHub repository: HTTP/3 in Docker Compose via Traefik.