Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support HTTP/3 #4475

Closed
cdauth opened this issue Feb 11, 2024 · 1 comment
Closed

Support HTTP/3 #4475

cdauth opened this issue Feb 11, 2024 · 1 comment
Labels
area:core issues describing changes to the core of uptime kuma blocked-upstream upstream (i.e. a dependency we depend on will have to do this work) feature-request Request for new features to be added

Comments

@cdauth
Copy link

cdauth commented 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 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

@cdauth cdauth added the feature-request Request for new features to be added label Feb 11, 2024
@CommanderStorm CommanderStorm added area:core issues describing changes to the core of uptime kuma blocked-upstream upstream (i.e. a dependency we depend on will have to do this work) labels Feb 11, 2024
@CommanderStorm
Copy link
Collaborator

CommanderStorm commented 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 nodejs/node#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 nodejs/node#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 ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:core issues describing changes to the core of uptime kuma blocked-upstream upstream (i.e. a dependency we depend on will have to do this work) feature-request Request for new features to be added
Projects
None yet
Development

No branches or pull requests

2 participants