Version of KrakenD you are using
2.13.7
Is your feature request related to a problem? Please describe.
RFC 10008 (June 2026) standardizes a new HTTP method, QUERY, as a
safe/idempotent method that can carry a request body. It fills the gap
between GET and POST: it lets clients send complex read-only queries
(e.g. JSONPath, SQL, XSLT-based filters) without the URL-length limits
of GET, while keeping the safe/idempotent semantics that POST lacks —
which matters for caching, retries, and circuit-breaking. KrakenD
currently only recognizes the classic HTTP verbs (GET, POST, PUT,
PATCH, DELETE, HEAD, OPTIONS) in its endpoint configuration, so it's
not possible to expose or proxy a QUERY endpoint through the gateway
today.
Describe the solution you'd like
- Add
QUERY as an accepted value for endpoint.method in the
configuration validation.
- Allow QUERY requests to be routed (gin router) and proxied to
backends with a request body, similar to how POST/PUT/PATCH bodies
are handled.
- Treat QUERY as safe/idempotent in caching, rate-limiting, and
retry/circuit-breaker logic — GET-like semantics, with POST-like
body support.
- Support the
Accept-Query response header defined in RFC 10008
§3, so backends can advertise supported query media types through
the gateway.
- Update the documentation to list QUERY as a supported method.
Describe alternatives you've considered
- Using POST as a workaround, but this loses the safe/idempotent
semantics and breaks caching assumptions.
- Encoding complex filters into the query string, but this hits URL
length limits and complicates client implementations for larger
queries.
Additional context
RFC 10008, "The HTTP QUERY Method" (June 2026):
https://datatracker.ietf.org/doc/html/rfc10008
IANA has already registered QUERY in the HTTP Method Registry as
safe/idempotent. Given it's now a Proposed Standard rather than just a
draft, adoption by clients/frameworks is likely to accelerate, so
native support in the gateway would help API teams expose
forward-compatible endpoints.
Version of KrakenD you are using
2.13.7
Is your feature request related to a problem? Please describe.
RFC 10008 (June 2026) standardizes a new HTTP method, QUERY, as a
safe/idempotent method that can carry a request body. It fills the gap
between GET and POST: it lets clients send complex read-only queries
(e.g. JSONPath, SQL, XSLT-based filters) without the URL-length limits
of GET, while keeping the safe/idempotent semantics that POST lacks —
which matters for caching, retries, and circuit-breaking. KrakenD
currently only recognizes the classic HTTP verbs (GET, POST, PUT,
PATCH, DELETE, HEAD, OPTIONS) in its endpoint configuration, so it's
not possible to expose or proxy a QUERY endpoint through the gateway
today.
Describe the solution you'd like
QUERYas an accepted value forendpoint.methodin theconfiguration validation.
backends with a request body, similar to how POST/PUT/PATCH bodies
are handled.
retry/circuit-breaker logic — GET-like semantics, with POST-like
body support.
Accept-Queryresponse header defined in RFC 10008§3, so backends can advertise supported query media types through
the gateway.
Describe alternatives you've considered
semantics and breaks caching assumptions.
length limits and complicates client implementations for larger
queries.
Additional context
RFC 10008, "The HTTP QUERY Method" (June 2026):
https://datatracker.ietf.org/doc/html/rfc10008
IANA has already registered QUERY in the HTTP Method Registry as
safe/idempotent. Given it's now a Proposed Standard rather than just a
draft, adoption by clients/frameworks is likely to accelerate, so
native support in the gateway would help API teams expose
forward-compatible endpoints.