WebServer Protection: GZIP encoding of proxied HTTP traffic
The WAF strips the Accept-Encoding header from client requests, which is fine, as compression is not generally useful between the origin server and the proxy. However, it doesn't use the header itself, either. It doesn't compress proxied traffic before returning it to the client. Interestingly, pages generated by the WAF itself (such as error documents) are compressed. Only the proxied content remains uncompressed, and this can have a substantial impact on page speed.
Benjamin Jakob commented
Moreover, it would be great to have support for brotli compression which most modern browsers already support. What a web client requests should be returned, not only from a web server but also from a state-of-the-art WAF.
This is similar to the discussion going on in this thread:
Elmar Haag commented
I am pretty sure this behavior has been fixed in 9.1. The WAF delivers web pages compressed to the requesting client by default. You can turn that off in the virtual webserver profile (advanced settings)
This is a good idea, but there should be a warning that CPU usage will increase somewhat on the UTM.
Nowadays just incredible
James White commented
This is really stupid and means I can't use WebServer protection on any sites that need SEO or a fast response as having no gzip adds a big speed penalty.