On 20.06.26 07:46, Julien Riou wrote:
The first change drifting from the initial implementation is this patch
uses the same port for both proxy protocol aware connections and for not
proxy protocol aware connections. To follow the spec, if a connection
comes from a trusted network but doesn't provide the PROXY header, the
server will reject it. Having only one port to listen is simpler from an
operator point of view. No need to configure and document more
networking rules. Existing rules will work as usual.
I'm not sure about this change. I can see both sides.
The original patches from Magnus had a proxy_port setting; this patch
has a proxy_networks setting. With the proxy_port setting, you need to
drill a hole for another port in your network setup, sure, but with the
proxy_networks setting you are then on a given host stuck with only
using the proxy protocol, unless you add another IP address, which is
probably even more complicated than allowing another port. Also, I
think relying on IP addresses will always cause some IPv4 vs. IPv6
confusion. And the way you have written it, it appears that all or no
Unix-domain sockets are included into the proxy networks, but note that
one can configure more than one Unix-domain socket, so one might also
want to treat those differently.
I don't know what the best solution here is. Ideally, I would like some
generalized facility to list socket endpoints (like listen_addresses =
'network:port,network:port,...'), and then you can make parallel
settings for proxy endpoints, direct-SSL endpoints, etc. Everything
else will only allow you to configure one particular slice of these
possibilities, but I don't know which particular slicing would be most
useful. What are some precedents that other products that support the
proxy protocol use for their configuration?
