Willy, 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. >> A last: Maybe it makes sense to create a log message if this limit is >> hit instead of silently ignoring (security critical!) response headers? > > Well, a long time ago we would get a 400 when trying to add or modify > a header increasing the request size past the max buffer size, or a 502 > when doing this on the response. The single fact that it didn't occur > in your case sounds like a bug to me. I suspect that along the > implementation of all these http-request / http-response rulesets, we > may have lost some failure checks in some gray areas (ie: when calling > a Lua service or stuff like this, it's not always black or white). Thus > I guess we need to recheck all of this to ensure we're not missing anything > important because I totally agree with you that a request not fullfilling > all the prerequisites for complete processing should not pass ; same for > responses. > 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 So it works like documented. But that does not mean that the current documented behaviour is a good behaviour. Best regards Tim Düsterhus
