Envoy support HTTP Query Method (RFC 10008)

[zufardhiyaulhaq]

Title: Envoy support HTTP Query Method (RFC 10008)

Description:
Currently, Envoy is not supporting HTTP Query Method and return 400 Bad Request. HTTP Query method has been released in June 2026. is there any timeline to start supporting this method?

[optional Relevant Links:]

1. https://datatracker.ietf.org/doc/html/rfc10008

[wbpcode]

cc @yanavlasov @ggreenway

[guy-with-a-why]

Hi @wbpcode . I'm new to Envoy and would like to contribute. Right now I'm at level 0, learning Envoy's architecture and intent.

Timeline permitting, I could be helpful here because I have a background reading RFCs, understanding network protocols and implementing support for them in other projects.

[guy-with-a-why]

Title: Envoy support HTTP Query Method (RFC 10008)

Description: Currently, Envoy is not supporting HTTP Query Method and return 400 Bad Request. HTTP Query method has been released in June 2026. is there any timeline to start supporting this method?

[optional Relevant Links:]

1. https://datatracker.ietf.org/doc/html/rfc10008

As a first step I'll reproduce the 400 locally and map the affected code paths across the HTTP/1 and HTTP/2/3 codecs, then follow up with a proposed minimal scope. Is the issue open for me to work toward a PR on that basis?

[guy-with-a-why]

Hi @zufardhiyaulhaq,

I've reproduced and root-caused this.

Reproduction

An HTTP QUERY request returns 400 over HTTP/1.1 but is forwarded (200) over HTTP/2, using an identical body and route to a working POST control, so the method token is the sole trigger. HTTP/3 shares HTTP/2's header-frame model with no HTTP/1-style method allowlist, so it should be unaffected for the same reason (not separately tested).

Cause

The HTTP/1 path rejects it in isMethodValid() in source/common/http/http1/balsa_parser.cc. With allow_custom_methods disabled (the default) in the configuration YAML, the method token is binary-searched against the hardcoded kValidMethods list, which omits QUERY, producing:

[2026-07-31 20:04:34.394][16][debug][http] [source/common/http/conn_manager_impl.cc:464] [Tags: "ConnectionId":"0"] dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD

HTTP/2 and HTTP/3 have no equivalent allowlist, so they already forward it.

I confirmed this by setting allow_custom_methods: true in the Envoy configuration YAML, after which the same HTTP/1 QUERY returns 200 and routes normally. So simply recognising the method is sufficient. That flag is a broad opt-in accepting any token method, though; explicitly recognising a now IANA-registered standard method seems preferable for correct out-of-the-box behaviour.

Proposed minimal scope, appropriate to Envoy's role as a proxy:

• Add QUERY to kValidMethods (kept sorted), fixing the HTTP/1 rejection.
• Integration tests asserting QUERY is forwarded across HTTP/1 and HTTP/2 (and HTTP/3), with a before-state assertion on the HPE_INVALID_METHOD / http1.codec_error rejection.
• Open question for you: whether to also add a QUERY constant to MethodValues and include it in Http::Utility::isSafeRequest(), since QUERY is safe and idempotent, noting the 0-RTT early-data implications of a method that carries a body.

Out of scope here, as origin-server rather than proxy concerns: body-keyed caching and the Accept-Query response field.

Does this scope match your intent? If so, I'll open a draft PR on that basis.