On Sat, Apr 04, 2020 at 01:49:06PM +0200, Tim Düsterhus wrote: > > Do you think we ought to refrain from sending any address at all ? > > I preferred to avoid possibly visible changes and apparently it didn't > > go that well :-/ > > > > Based on a strict reading of the proxy protocol definition Dovecot is > wrong here: > > > The receiver must accept this connection as valid and must use the > > real connection endpoints and discard the protocol block including the > > family which is ignored.
Sure but one component being wrong doesn't deserve being broken by a unilateral change :-/ > To my understanding the TLV are part of the protocol block, because they > were bolted onto the proxy protocol v2 after the fact in commit > afb768340c9d7e50d8e7372051c8a9c3b3f2151c > (https://github.com/haproxy/haproxy/commit/afb768340c9d7e50d8e7372051c8a9c3b3f2151c). > I also notice that this commit made an incompatible change to proxy > protocol v2 1.5 years after the initial specification (however both > during the 1.5 development cycle). Yes TLVs were added after the initial v2 spec. > However HAProxy violates a should: > > > When a sender presents a > > LOCAL connection, it should not present any address so it sets this field to > > zero. So that fuels the fact that we should definitely get rid of these addresses and we should possibly expect less breakage by doing so. > My conclusion is that the proxy protocol v2 definition is not super > clear with regards to TLV. I assume that is because they were not > initially part of the specification. Not sending an explicit length for > the address and instead only a length for address + TLV is non-ideal. > Another case in point: My bugfix for the TLV parsing that ignored the > length of the proxy header, because each TLV had its own length. So I think that I'll revert the fix from stable branches, because it was meant to address bug #511 which is not that important. And in master we'd instead send a real, naked LOCAL request that complies with the rule above. Hativ, if I send you a patch to test next week, is it possible to give it a try on your side ? I'm interested in knowing if a clean "LOCAL" connection works fine with Dovecot. If so then in parallel we can file a report on Dovecot to make their parser more robust but at least we'd have a longterm solution that doesn't affect deployed servers. Thanks! Willy
