Yes, the exact same configuration file, no caching or threads. We've not tried HTTP/2 just yet, I'll have a look at this when I'm in the office tomorrow.
Thanks On 1 Feb 2018 19:31, "Willy Tarreau" <[email protected]> wrote: Hi guys, On Thu, Feb 01, 2018 at 06:16:32PM +0100, Lukas Tribus wrote: > Hello Martin, > > On 1 February 2018 at 17:18, Martin Goldstone <[email protected]> wrote: > > Hi, > > > > We've been using haproxy in docker for quite some time to provide reverse > > proxy facilities for many and varied application servers. Typically, we've > > always used option http-server-close in the config, except for rare > > occasions where we might need http-keep-alive (eg ntlm authentication). We > > also have the following in our front end configs: > > > > compression algo gzip > > compression type text/html application/x-javascript text/css > > application/javascript text/javascript text/plain text/xml application/json > > application/vnd.ms-fontobject application/x-font-opentype > > application/x-font-truetype application/x-font-ttf application/xml font/eot > > font/opentype font/otf image/svg+xml image/vnd.microsoft.icon > > > > These have been working fine up to and including the most recent release of > > 1.7. We've recently began re-engineering our reverse proxy set up, and as > > part of this we want to move to 1.8. However, we've discovered that some > > resources requested by web pages (mainly javascript and css) don't load > > properly when using haproxy 1.8 with these options. Basically, the page > > doesn't display and the developer toolbar in Chrome gives an error of > > net::ERR_INCOMPLETE_CHUNKED_ENCODING or net::ERR_INVALID_CHUNKED_ ENCODING > > against the resources that failed to load in the network pane. I haven't > > been able to determine yet why this doesn't apply to every resource the page > > attempts to load, but in this case out of 20 javascript and css files, 5 > > fail to load. > > > > [...] > > Can anyone offer any advice? > > Ok, so this is clearly a bug that has to be fixed. I really don't see anything changing in the compression area between 1.7 and 1.8, so I'm afraid we might have been breaking something somewhere else :-( Just to be sure Martin, are you using the same configuration ? No threads nor caching for example (just trying to narrow down the problem) ? > > We've noticed that the problem goes away when using option http-keep-alive > > and option http-pretend-keepalive, but as the documentation suggests that > > http-server-close is the preferred option, we'd prefer to stick with that. That's a very very useful element. So there might be some breakage in the way we manage the analysers or filters at the end of the request. I think we had some changes in this area during 1.8. > Yeah, that comment in the documentation stems from the introduction of > keepalive support 8 years ago (commit 16bfb021 "MINOR: config: add > option http-keep-alive"), I think it should be removed now. We made > http-keep-alive the default mode 4 years ago (commit 70dffdaa "MAJOR: > http: switch to keep-alive mode by default") and everyone is using it > nowadays, which is why you are seeing this unfixed bug in those old > close modes as opposed to http-keep-alive. I agree this definitely makes sense. I'm wondering whether it surfaces when using HTTP/2 (haproxy.org runs with both H2 and compression and we didn't get any such report yet though). > Really http-keep-alive is what you should use in haproxy 1.8 (and > 1.7), as it gets all the testing (filters, compression, HTTP/2) and > everyone is using that (default) mode. Keep-alive is safe as it does > not reuse session between different sessions by default: > http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-http- reuse > > > If there is agreement (Willy?) I can send a doc patch removing that paragraph. Oh yes please, thanks for the offer Lukas! Willy
