Hello Willy, > 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.
I didn't get a patch so far. Am Samstag, den 04.04.2020, 14:17 +0200 schrieb Willy Tarreau: > 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'tgo that well :-/ > > > > Based on a strict reading of the proxy protocol definition Dovecot > > iswrong here: > > > The receiver must accept this connection as valid and must use > > > thereal connection endpoints and discard the protocol block > > > including thefamily which is ignored. > > Sure but one component being wrong doesn't deserve being broken by > aunilateral change :-/ > > To my understanding the TLV are part of the protocol block, because > > theywere bolted onto the proxy protocol v2 after the fact in > > commitafb768340c9d7e50d8e7372051c8a9c3b3f2151c( > > https://github.com/haproxy/haproxy/commit/afb768340c9d7e50d8e7372051c8a9c3b3f2151c).I > > also notice that this commit made an incompatible change to > > proxyprotocol v2 1.5 years after the initial specification (however > > bothduring the 1.5 development cycle). > > Yes TLVs were added after the initial v2 spec. > > However HAProxy violates a should: > > > When a sender presents aLOCAL connection, it should not present > > > any address so it sets this field tozero. > > So that fuels the fact that we should definitely get rid of > theseaddresses and we should possibly expect less breakage by doing > so. > > My conclusion is that the proxy protocol v2 definition is not > > superclear with regards to TLV. I assume that is because they were > > notinitially part of the specification. Not sending an explicit > > length forthe address and instead only a length for address + TLV > > is non-ideal.Another case in point: My bugfix for the TLV parsing > > that ignored thelength of the proxy header, because each TLV had > > its own length. > > So I think that I'll revert the fix from stable branches, becauseit > was meant to address bug #511 which is not that important. And > inmaster we'd instead send a real, naked LOCAL request that > complieswith the rule above. > Hativ, if I send you a patch to test next week, is it possible to > giveit 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 filea report on Dovecot to make their parser more robust but at > least we'dhave a longterm solution that doesn't affect deployed > servers. > Thanks!Willy -- Greetings Hativ
