Your idea sounds interesting, and I can see a benefit as well especially for the mentioned use cases (AWS and haproxy setups). Daniel has probably also some comments on this, but in my opinion your approach sounds reasonable.
- Add a core variable, e.g. ksr_tcp_accept_proxy
- add a function to parse the proxy protocol(s), like tcp_read_proxy_protocol(..)
- probably it makes sense to add a own flag for this as well to check the proper parsing later on (similar to the hep3 execution path)
- call the tcp_read_proxy_protocol() in tcp_read_req(..)
- add also a proxy_process_msg(..) function to actually use the data to set the internal connection information(s)
- then check the flag in receive_tcp_msg(..) and call this function, after your special handling related to the proxy protocol call the normal receive_msg(..) function to process the payload
Just to show you one possible approach (obviously from a high level view).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.