Support Early Request Body Access for Dynamic Upstream Peer Selection

[pinghe]

What is the problem your feature solves, or the need it fulfills?

Currently, the request_body_filter runs after the upstream_peer selection phase, making it impossible to choose an upstream peer based on the actual content of the request body (e.g., fields in a JSON payload). This limits the ability to implement content-aware routing in scenarios such as API gateways or intelligent load balancers. This feature is needed by users who require dynamic, payload-driven upstream routing decisions.

Describe the solution you'd like

Introduce an early_request_body_filter (or a similarly named phase/hook) that executes before the upstream_peer selection. This filter would allow the request body to be read, parsed, and buffered early in the request lifecycle, enabling the upstream_peer logic to inspect the body content and make routing decisions accordingly. The implementation should ensure compatibility with existing filters and avoid unnecessary performance overhead when not used.

Describe alternatives you've considered

• Buffer the body manually before upstream_peer: Not feasible without core changes, as the current filter chain order is fixed.
• Use headers instead of body content: Requires clients to duplicate critical routing information in headers, which is redundant and breaks API design principles.
• Postpone peer selection until after request_body_filter: Would require significant refactoring of the upstream pipeline and may complicate error handling and streaming scenarios.

Compared to these, adding an explicit early body access point is cleaner, more modular, and aligns with existing filter-based architectures.

Additional context

This capability is common in advanced API gateways (e.g., Envoy’s HTTP filters can access buffered request bodies early for routing). Supporting this would greatly enhance flexibility for use cases like:

• Routing GraphQL queries based on operation name
• Sending requests to different microservices based on a tenant_id in the JSON body
• Conditional canary deployments driven by payload content

Currently, such logic cannot be implemented without forking or extensive workarounds.

[rxdiscovery]

Why not simply change the execution order of the phases and make request_body_filter run before upstream_peer?
Instead of adding another phase that would only cause a performance loss due to an additional method call in the phase execution cycle.