Issue link: https://read.uberflip.com/i/1146286
34 | Chapter 4: Rule 4: Gzip Components Edge Cases The coordination of compression between servers and clients seems simple, but it must work correctly. The page could easily break if either the client or server makes a mistake (sending gzipped content to a client that can't understand it, forgetting to declare a compressed response as gzip-encoded, etc.). Mistakes don't happen often, but there are edge cases to take into consideration. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip. If a browser says it supports gzip you can generally trust it. There are some known bugs with unpatched early versions of Internet Explorer, specifically Internet Explorer 5.5 and Internet Explorer 6.0 SP1, and Microsoft has published two Knowledge Base articles documenting the problem (http://support.microsoft.com/ kb/313712/en-us and http://support.microsoft.com/kb/312496/en-us). There are other known problems, but they occur on browsers that represent less than 1% of Internet traffic. A safe approach is to serve compressed content only for browsers that are proven to support it, such as Internet Explorer 6.0 and later and Mozilla 5.0 and later. This is called a browser whitelist approach. With this approach you may miss the opportunity to serve compressed content to a few browsers that would have supported it. The alternative—serving compressed content to a browser that can't support it—is far worse. Using mod_gzip in Apache 1.3, a browser whitelist is specified using mod_gzip_item_include with the appropriate User-Agent values: mod_gzip_item_include reqheader "User-Agent: MSIE [6-9]" mod_gzip_item_include reqheader "User-Agent: Mozilla/[5-9]" In Apache 2.x use the BrowserMatch directive: BrowserMatch ^MSIE [6-9] gzip BrowserMatch ^Mozilla/[5-9] gzip Adding proxy caches to the mix complicates the handling of these edge case brows- ers. It's not possible to share your browser whitelist configuration with the proxy. The directives used to set up the browser whitelist are too complex to encode using HTTP headers. The best you can do is add User-Agent to the Vary header as another criterion for the proxy. Vary: Accept-Encoding,User-Agent Once again, mod_gzip takes care of this automatically by adding the User-Agent field to the Vary header when it detects that you're using a browser whitelist. Unfortu- nately, there are thousands of different values for User-Agent. It's unlikely that the proxy is able to cache all the combinations of Accept-Encoding and User-Agent for all the URLs it proxies. The mod_gzip documentation (http://www.schroepl.net/projekte/