Hi Tim, On Sun, Apr 29, 2018 at 09:36:13PM +0200, Tim Düsterhus wrote: > Willy, > > Am 28.04.2018 um 07:51 schrieb Willy Tarreau: > > Not that many ideas. Could you retry by setting "tune.maxrewrite" to a > > larger value ? It defaults to 1024, and maybe you're already adding 1kB > > of response and there's no more room in the response buffer. It's just > > a guess, I could be completely wrong. > > I configured it as 1536 and it seems to have fixed the issue. Indeed I > am settings a few very large headers: The Content-Security-Policy header > I'm setting is 410 bytes on it's own. The Public-Key-Pins-Report-Only > header is an additional 258 bytes. > > I'm wondering why I am unable to reproduce the issue consistently, > though. The only dynamic header I am setting with haproxy is: > > http-response set-header X-Req-ID %[unique-id] > > and that one does not differ in length. Either it should fit in the > buffer all the time or it should never fit, no? > > 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. > 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. Thanks, Willy
