starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Support for selecting HTTP client version (`HTTP/1.0`, `HTTP/1.1`, `HTTP/2`, `HTTP/3`) #3178

New issue

Open

opened 2026-02-28 03:20:42 -05:00 by deekerman · 4 comments

deekerman commented

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

Owner

Originally created by @ilogus on GitHub (Mar 7, 2024).

After searching through the existing issues and pull requests, I have not found any that directly address the ability to select the version of the HTTP client for HTTP monitors. This feature seems to be unique and has not been discussed or proposed previously.

🏷️ Feature Request Type

Change to existing monitor, Settings

🔖 Feature description

The feature I am proposing is to introduce the ability for users to select the version of the HTTP client used for HTTP monitoring tasks. This would provide additional flexibility and control over monitoring, allowing users to tailor their monitoring more closely to their specific needs and the requirements of the websites or services they are tracking. For instance, being able to choose between HTTP/1.1, HTTP/2, or even HTTP/3 could be crucial for accurately monitoring and diagnosing issues with modern web services that may rely on specific HTTP versions for optimal performance 😄

✔️ Solution

The proposed solution involves adding a dropdown menu or a similar selection mechanism in the HTTP(s) monitor creation and edit screens, enabling users to choose the HTTP version their monitor should use for requests. This selection would then dictate how the monitor performs HTTP requests, ensuring compatibility and providing more detailed monitoring capabilities. It could also include an auto-detect feature that selects the best HTTP version based on the initial handshake with the target server, offering a balance between flexibility and ease of use.

Additionally, it is worth noting that it is currently unclear whether the existing HTTP client library used by Uptime Kuma supports easy switching between different HTTP protocol versions.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @ilogus on GitHub (Mar 7, 2024). ### 📑 I have found these related issues/pull requests After searching through the existing issues and pull requests, I have not found any that directly address the ability to select the version of the HTTP client for HTTP monitors. This feature seems to be unique and has not been discussed or proposed previously. ### 🏷️ Feature Request Type Change to existing monitor, Settings ### 🔖 Feature description The feature I am proposing is to introduce the ability for users to select the version of the HTTP client used for HTTP monitoring tasks. This would provide additional flexibility and control over monitoring, allowing users to tailor their monitoring more closely to their specific needs and the requirements of the websites or services they are tracking. For instance, being able to choose between HTTP/1.1, HTTP/2, or even HTTP/3 could be crucial for accurately monitoring and diagnosing issues with modern web services that may rely on specific HTTP versions for optimal performance 😄 ### ✔️ Solution The proposed solution involves adding a dropdown menu or a similar selection mechanism in the HTTP(s) monitor creation and edit screens, enabling users to choose the HTTP version their monitor should use for requests. This selection would then dictate how the monitor performs HTTP requests, ensuring compatibility and providing more detailed monitoring capabilities. It could also include an auto-detect feature that selects the best HTTP version based on the initial handshake with the target server, offering a balance between flexibility and ease of use. Additionally, it is worth noting that it is currently unclear whether the existing HTTP client library used by Uptime Kuma supports easy switching between different HTTP protocol versions. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:monitor

type:enhance-existing

blocked-upstream

labels

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

deekerman commented

2026-02-28 03:20:45 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 7, 2024):

We are using axios under the hood to make network requests.

for supporting http/2 there is conflicting information out there.
If somebody more experienced has a clue what is the correct answer, comments would be appreciated.
- axios uses node's network stack (XMLHttpRequest).
  
  The browser decides which protocol it wants to use as an implementation detail of the XmlHttpRequest object. You can't force a particular choice from inside your script.
  
  According to https://stackoverflow.com/questions/56675358/is-there-a-way-to-force-an-xmlhttprequest-to-use-http-1-1
- In https://github.com/axios/axios/issues/1175 https://github.com/uibakery/axios-http2-adapter was mentioned as a workaround for this limitation. I don't think have investigated this yet.
http/3 is 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!).

Given that http2 might be possible with deeper hacks into our requesst library, I am going to keep this issue open (different from https://github.com/louislam/uptime-kuma/issues/4475)

@CommanderStorm commented on GitHub (Mar 7, 2024): We are using `axios` under the hood to make network requests. - for supporting http/2 there is conflicting information out there. If somebody more experienced has a clue what is the correct answer, comments would be appreciated. - `axios` uses node's network stack (`XMLHttpRequest`). > The browser decides which protocol it wants to use as an implementation detail of the XmlHttpRequest object. You can't force a particular choice from inside your script. According to https://stackoverflow.com/questions/56675358/is-there-a-way-to-force-an-xmlhttprequest-to-use-http-1-1 - In https://github.com/axios/axios/issues/1175 https://github.com/uibakery/axios-http2-adapter was mentioned as a workaround for this limitation. I don't think have investigated this yet. - http/3 is 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!). Given that http2 might be possible with deeper hacks into our requesst library, I am going to keep this issue open (different from https://github.com/louislam/uptime-kuma/issues/4475)

deekerman commented

2026-02-28 03:20:45 -05:00

Author

Owner

@mariuszste commented on GitHub (May 21, 2024):

axios uses node's network stack (XMLHttpRequest).

that is only true when running in a browser, XMLHttpRequest (and as of recently in Axios also fetch) are browser APIs. When running under node it uses the node:http/node:https modules that do not support http2 (hence the missing http2 support issue). Some people made http2 adapters (not sure about the quality of these) and there is a way to use a http2 wrapper that acts like node:http and monkey patch that but that's even more hacky than an adapter.

@mariuszste commented on GitHub (May 21, 2024): > axios uses node's network stack (XMLHttpRequest). that is only true when running in a browser, XMLHttpRequest (and as of recently in Axios also fetch) are browser APIs. When running under node it uses the `node:http`/`node:https` modules that do not support http2 (hence the missing http2 support issue). Some people made http2 adapters (not sure about the quality of these) and there is a way to use a http2 wrapper that acts like `node:http` and monkey patch that but that's even more hacky than an adapter.

deekerman commented

2026-02-28 03:20:45 -05:00

Author

Owner

@strarsis commented on GitHub (Aug 31, 2024):

There is a new monitor type HTTP(s) - Browser Engine (Chrome/Chromium) (Beta), I just noticed. Chrome should already support HTTP/3. So this should allow for testing HTTP/3 and the other connection types that Chrome may select.

@strarsis commented on GitHub (Aug 31, 2024): There is a new monitor type `HTTP(s) - Browser Engine (Chrome/Chromium) (Beta)`, I just noticed. Chrome should already support HTTP/3. So this should allow for testing HTTP/3 and the other connection types that Chrome may select.

deekerman commented

2026-02-28 03:20:45 -05:00

Author

Owner

@vigo commented on GitHub (Mar 2, 2025):

i've justed tested with the pages i host on github pages, static html sites. only OPTIONS method worked. GET, HEAD returned error, "site is down".

@vigo commented on GitHub (Mar 2, 2025): i've justed tested with the pages i host on github pages, static html sites. only OPTIONS method worked. GET, HEAD returned error, "site is down".