docs(http): document HTTP/3 support via reverse proxy and track native HTTP/3 follow-up #1736

Overview

The tracker demo currently exposes HTTP services behind Caddy, and HTTP/3 support can be provided at the edge by enabling QUIC/UDP 443 on the proxy. This works even when backend tracker HTTP services are still served over the existing HTTP stack.

This issue proposes documenting that deployment model in the tracker project, and also creating a clear follow-up reminder to test and evaluate direct/native HTTP/3 support in tracker HTTP services once the Rust HTTP ecosystem used by the project supports it in stable releases.

Why this issue

1. Operators may assume tracker services themselves must already support native HTTP/3 to offer HTTP/3 to clients, which is not required when using an edge proxy.
2. The project should avoid losing track of native HTTP/3 adoption once upstream dependencies mature.

Scope

1. Document how to provide HTTP/3 for tracker HTTP endpoints using a reverse proxy (for example Caddy) in front of the tracker.
2. Add a future-facing reminder to validate and benchmark direct/native HTTP/3 support in tracker HTTP services when supported by upstream crates and frameworks.

Proposed documentation additions

1. Add a short section in deployment docs describing protocol boundaries:
   • Client -> proxy may use HTTP/3.
   • Proxy -> tracker backend may remain HTTP/1.1 or HTTP/2 depending on proxy/backend setup.
2. Add an example Caddy configuration note for enabling UDP 443 (QUIC) at the edge.
3. Add operational notes:
   • HTTP/3 enablement at proxy is optional and reversible.
   • Operators should monitor CPU/load and request behavior after enabling.

Native HTTP/3 follow-up

Create or link a follow-up task that is explicitly blocked on upstream support readiness, then evaluate:

1. Functional correctness for announce/scrape and API routes over direct HTTP/3.
2. Performance and resource usage compared to proxy-terminated HTTP/3.
3. Migration impact and backward compatibility.

Acceptance criteria

• Tracker docs explain how HTTP/3 can be offered through a reverse proxy today.
• Docs clearly distinguish edge protocol support from backend protocol support.
• A follow-up task exists to test direct/native tracker HTTP/3 once upstream support is available.
• The follow-up task includes a minimal test/benchmark checklist.

Suggested references

• Demo deployment pattern using Caddy edge proxy and tracker backend HTTP services.
• Upstream Hyper/Axum HTTP/3 readiness tracking before native adoption in tracker services.
• docs(issue): re-enable caddy http3 and document issue-29 rationale torrust-tracker-demo#31
• WIP: Add HTTP/3 support hyperium/hyper#3925