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.


Reply via email to