On Mon, Apr 30, 2018 at 09:06:16PM +0200, Tim Düsterhus wrote: > Am 30.04.2018 um 15:48 schrieb Willy Tarreau: > >> And why does it affect two headers at once? If the length is right below > >> the limit intuitively only the very last header should be affected. > > > > I really don't know, maybe the rules are aborted during their processing. > > Anything I could do to help investigate this? I can apply patches with > additional logging or I can send you the unredacted configuration in > private if that would help.
OK, it's just that for now I can't propose anything, I'm context-switching far too much between many many different stuff :-( > tune.bufsize is documented to send a 502: > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#3.2-tune.bufsize > > tune.maxrewrite is documented to "prevent addition of headers": > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#3.2-tune.maxrewrite No, not "prevent addition of headers", in fact it's the exact opposite, it's meant to ensure that a received message will not fill a header so that this number of bytes will always remain available to permit addition of headers. Now I can understand how it's possible to read the doc like this, but what is meant there is that if it's too small, as a side effect it will indeed prevent the addition of headers, but this will result in the message not to be correctly processed and to fail (thus 400 or 502 depending on the direction) since the resulting message becomes larger than tune.bufsize. > So it works like documented. No, really not. The doc explains a consequence, not a goal (though it may not be that obvious). > But that does not mean that the current > documented behaviour is a good behaviour. Absolutely. What I'm much more worried about now is that a number of deployments may already accidently be relying on this problem and may discoverr 400s or 502s the hard way after we fix it :-( So we'll have to be very careful about this and enumerate what works and what fails to figure if there's a real risk that people rely on this or not. If so we may need to add an extra option to relax addition in case of failure to preserve the current behaviour, which I'd personally hate. Regards, Willy
