Hi Christopher, This did help. The buffer seemed to have been exhausted. Increasing it by 100 bytes to 1124 got the issue resolved.
Thank you so much for your response. It was really helpful :) Thanks! Regards, Narendra Patel On Fri, Oct 21, 2022 at 12:48 PM Christopher Faulet <cfau...@haproxy.com> wrote: > Le 10/21/22 à 08:16, Narendra Patel a écrit : > > Hi Team, > > > > We are having one issue with routing traffic through HAProxy. > > > > Have configured IPv6 for our Google load balancer backed by HAProxy. The > > architecture looks like below: > > > > GLB --> L1 HAProxy --> Kong Gateway --> L2 HAProxy --> App node > > > > L1 HAProxy has the logic for compression. > > > > # zlib Compression > > compression algo gzip > > compression type text/html text/tab-separated-values text/plain > text/xml > > text/csv text/css text/javascript application/xml > application/x-javascript > > application/javascript > > > > But while evaluating IPv6, we are seeing one peculiar error. For IPV6 > request > > for a css file, we see that HAProxy injects a "Content-Encoding: gzip" > Header, > > but does not really compress the file thus corrupting the response. > > > > We tried doing a tcpdump on L1 HAProxy and Kong to check. > > Besides the `x-forwarded-for` header, HAProxy sends the same request to > Kong for > > both IPv4 and IPv6. > > Also Kong responds with the same header values in response to HAProxy > for both > > IPv4 and IPv6. > > Content length also is the same in Kong's response to HAProxy for both > IPv4 and > > IPv6. So Kong is not doing any compression. > > > > HAProxy version is : HAProxy version 2.6.4-2a2078c 2022/08/22 > > > > Attaching the tcpdump details for HAProxy and Kong for both IPv4 and > IPv6. Have > > masked a few values for compliance. > > > > P.S: We are on GCP and the IPv6 setup looks like this : > > > https://cloud.google.com/load-balancing/docs/ipv6#ipv6_termination_and_proxy > > < > https://cloud.google.com/load-balancing/docs/ipv6#ipv6_termination_and_proxy > > > > > > Any directions on this would be really appreciated. > > Hi, > > In the HAProxy IPv6 tcpdump, there is no "Vary" header. It means HAProxy > fails > to add it. When this happens, an error is triggered and the compression is > not > performed. So here, there is an issue because "Content-Encoding" header is > not > removed while it should be. As a workaround, you may try to increase > "tune.maxrewrite" value in the global section. It seems you add several > headers > in your L1 HAProxy, exceeding the default reserve (1024 bytes). If the > response > payload is received with the headers, the buffer may be full, preventing > some > headers additions. > > Note that it may also happen on any headers added via http-response rules. > In > this case, this will generate an internal error, and a 500 response will > be > returned to the client. So, we should fix the compression related error. > But, it > remains a good idea to increase "tune.maxrewrite" value in your case. > > Regards, > -- > Christopher Faulet > >
