Support HTTP/3 #3119

New issue

Closed

opened 2026-02-28 03:18:42 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 03:18:42 -05:00

Owner

Originally created by @cdauth on GitHub (Feb 11, 2024).

I was unable to find any related issues.

🏷️ Feature Request Type

Change to existing monitor

🔖 Feature description

Because I could not find any information about this, I am assuming that HTTP/3 is currently not supported in HTTP monitors. It would be nice to have an option where I can explicitly select to explicitly use HTTP/1 or HTTP/3. Ideally, there would be an option to check both as well.

Because HTTP/3 runs over UDP, its connection listener can not only run on a different port than its corresponding HTTP/1 listener, but its requests can be handled by a completely separate network setup in the background. For example, my server has a single public IP address but hosts multiple websites that run on different servers that only have local IP addresses but want to keep ownership of their TLS private keys. For this my server runs a HTTPS reverse proxy that forwards incoming HTTPS connections to the respective server using TLS passthrough based on the SNI of the request. Because I'm not aware of any reverse proxy that supports TLS passthrough for HTTP/3 though, I have assigned each local server a separate public port that uses a simple UDP port forward for HTTP/3. This means that HTTP/1 and HTTP/3 are separate points of failure, because HTTP/1 is handled by the reverse proxy, while HTTP/3 is handled by the iptables port forward.

There are also different ways to determine the port that should be used for HTTP/3. When opening https://example.org/, browsers will always use HTTP/1–2 on port 443 for the first request. If the response contains an Alt-Svc header, browsers will remember its value and use HTTP/3 on the advertised port for subsequent requests if supported. On the other hand, curl for example does not detect the port from the Alt-Svc header, but always uses port 443 by default. So if the HTTP/3 handler listens on port 500, the request would have to be made as curl --http3 https://example.org:500/.

In case of my setup I would need to run 4 checks for each HTTP endpoint, because each of these gets routed through a different network configuration: HTTP/1 via IPv4, HTTP/1 via IPv6, HTTP/3 via IPV4, HTTP/3 via IPv6.

✔️ Solution

Ideally, HTTP monitors would have an additional configuration option “HTTP protocol version” with the following options:

HTTP/1
HTTP/3
Both

Selecting "Both" would run two checks, one for each protocol version.

Ideally, the HTTP/3 check would make a HTTP/1 request to the website, check for its Alt-Svc header and then use that to make a HTTP/3 request, like the browsers do. If "Both" is selected, the HTTP/1 check could be used to check the connection and retrieve the Alt-Svc in one go. Having to specify the HTTP/3 port manually would be an option, but would make the "Both" option more challenging to configure, as both protocol versions might use different ports.

The option should be combinable with #1242 to check each of the HTTP protocol versions on each IPv4/IPv6.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @cdauth on GitHub (Feb 11, 2024). ### 📑 I have found these related issues/pull requests I was unable to find any related issues. ### 🏷️ Feature Request Type Change to existing monitor ### 🔖 Feature description Because I could not find any information about this, I am assuming that HTTP/3 is currently not supported in HTTP monitors. It would be nice to have an option where I can explicitly select to explicitly use HTTP/1 or HTTP/3. Ideally, there would be an option to check *both* as well. Because HTTP/3 runs over UDP, its connection listener can not only run on a different port than its corresponding HTTP/1 listener, but its requests can be handled by a completely separate network setup in the background. For example, my server has a single public IP address but hosts multiple websites that run on different servers that only have local IP addresses but want to keep ownership of their TLS private keys. For this my server runs a HTTPS reverse proxy that forwards incoming HTTPS connections to the respective server using TLS passthrough based on the SNI of the request. Because I'm not aware of any reverse proxy that supports TLS passthrough for HTTP/3 though, I have assigned each local server a separate public port that uses a simple UDP port forward for HTTP/3. This means that HTTP/1 and HTTP/3 are separate points of failure, because HTTP/1 is handled by the reverse proxy, while HTTP/3 is handled by the iptables port forward. There are also different ways to determine the port that should be used for HTTP/3. When opening `https://example.org/`, browsers will always use HTTP/1–2 on port 443 for the first request. If the response contains an [Alt-Svc](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc) header, browsers will remember its value and use HTTP/3 on the advertised port for subsequent requests if supported. On the other hand, curl for example does not detect the port from the `Alt-Svc` header, but always uses port 443 by default. So if the HTTP/3 handler listens on port 500, the request would have to be made as `curl --http3 https://example.org:500/`. In case of my setup I would need to run 4 checks for each HTTP endpoint, because each of these gets routed through a different network configuration: HTTP/1 via IPv4, HTTP/1 via IPv6, HTTP/3 via IPV4, HTTP/3 via IPv6. ### ✔️ Solution Ideally, HTTP monitors would have an additional configuration option “HTTP protocol version” with the following options: * HTTP/1 * HTTP/3 * Both Selecting "Both" would run two checks, one for each protocol version. Ideally, the HTTP/3 check would make a HTTP/1 request to the website, check for its `Alt-Svc` header and then use that to make a HTTP/3 request, like the browsers do. If "Both" is selected, the HTTP/1 check could be used to check the connection and retrieve the `Alt-Svc` in one go. Having to specify the HTTP/3 port manually would be an option, but would make the "Both" option more challenging to configure, as both protocol versions might use different ports. The option should be combinable with #1242 to check each of the HTTP protocol versions on each IPv4/IPv6. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman

2026-02-28 03:18:42 -05:00

closed this issue
added the
feature-request

A:core

blocked-upstream
labels

deekerman commented

2026-02-28 03:18:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 11, 2024):

Closing as currently impossible without changing the node API or other changes which we don't have the resources for (some mad lad from Cloudflare is trying to add 25-18K lines to Node.js in https://github.com/nodejs/node/pull/44325!).
We are using axios to make http-requests, which relies on the APIs provided by nodejs

Axios does under the hood use XMLHttpRequest, which does not have the option to specify which http-version is used.
See https://stackoverflow.com/questions/59264502/can-axios-be-configured-to-use-http-1-1

http/3 is also not quite supported by Node.js as far as I read https://github.com/nodejs/node/issues/38478

Given how far in the future, support for http/3 looks in JavaScript, I think closing it as CURRENTLY not planned is reasonable.
We can reopen if anything changes or if some of my assumptions were wrong ^^

@CommanderStorm commented on GitHub (Feb 11, 2024): Closing as **currently impossible without changing the node API** or other changes which we don't have the resources for (some mad lad from Cloudflare is trying to add 25-18K lines to Node.js in https://github.com/nodejs/node/pull/44325!). We are using `axios` to make http-requests, which relies on the APIs provided by `nodejs` Axios does under the hood use `XMLHttpRequest`, which does not have the option to specify which http-version is used. See https://stackoverflow.com/questions/59264502/can-axios-be-configured-to-use-http-1-1 http/3 is also not quite supported by Node.js as far as I read https://github.com/nodejs/node/issues/38478 Given how far in the future, support for http/3 looks in JavaScript, I think closing it as **CURRENTLY** not planned is reasonable. We can reopen if anything changes or if some of my assumptions were wrong ^^