programatik29 / axum-server

High level server designed to be used with axum framework.
MIT License
166 stars 54 forks source link

Feature Request: Extracting PROXY Protocol Header from TCP requests #86

Closed megsdevs closed 8 months ago

megsdevs commented 9 months ago

As a developer of an axum-server application, which runs behind a layer 3 load balancing technology, I need to extract the clients IP, which is passed through with the PROXY Protocol:

https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

I'd like to have axum-server optionally decode PROXY from the tcp stream and add it as an X-Forwarded-For or Forwarded header to the HTTP request.

I already started an implementation in axum-server which intercepts the tcp stream to check for PROXY header as a solution for my case.

I like the simplicity and functionality axum-server provides, and it was more straightforward for me to implement in the axum-server codebase than to write a lower level implementation from scratch using tokio to get access to the tcp stream.

I would like to know the receptiveness of the axum-server team for me putting forward a PR for this feature.

Additional context https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#client-ip-preservation

programatik29 commented 9 months ago

If using Accept trait is enough to implement this functionality, it might be a good idea to implement this in a separate crate. I'm open to implementing it in this codebase though. What are your thoughts?

megsdevs commented 9 months ago

Hey! Apologies for slow reply on this. We should have a PR out very soon for review. We have the proxy header encoding and decoding working in place, but now refactoring into a nice feature for axum_server. The Accept trait definitely seems like the way forward, thanks for the suggestion! It follows the same pattern as the tls acceptors which works nicely, but I'm currently trying to decide how to have it interact with the tls features. Because I am injecting the decoded IPs into the http request header, this needs to be done after tls, but the proxy header needs to be read before tls. So currently coming up with a structure for when users want to use tls with proxy protocol, so that the ip logic sandwiches the tls handshake.

megsdevs commented 9 months ago

to clarify this works in place when implemented in the server serve function, is a decision of how to refactor into a feature which can be used interchangeably with the tls features

megsdevs commented 9 months ago

i think solution seems to be to have an additional combined acceptor that can be created when both features are enabled