On 6/1/2010 7:05 AM, Eric Covener wrote: >> Typically, you >> would want to front a mod_deflate with an HTTP cache, such as mod_cache (or >> equivalent). Here mod_cache only makes sense if you have the disk space to >> support it, and there is no real one-size-fits-all cache setup. > >> This said, our default config is 15 years old, and attempts to disable >> deflate for browsers that don't support it, like "Netscape 4". Unless there >> are modern browsers that have broken protocol support for transfer encoding, >> these obsolete examples need to be removed. > > These go together a bit Vary, the current workarounds for old browsers > cause Vary: User-Agent which is quite a buzzkill for a cache!
Both is out of the question, for the reason you mention. I would argue for neither cache nor deflate, but for a bit different reason. But I see no reason to leave these out of modules 'most', to be ready for the user to deploy them. Cache should be disabled by default simply because it confuses beginning users, and we can't expect they will read all the relevant docs about setting proper expiries on their content. They will undoubtedly be lost, just as we've all been lost reconfiguring our servers and not realizing the 'refresh' wasn't a full refresh on IE, FF or what have you. It will generate too many invalid bug reports and user list queries. The current user list traffic around the cache module seems quite reasonable. Deflate should be disabled simply because the user can't trivially inspect the stream in forensics, and it interacts in odd ways once cache is enabled. I like to think of a fresh httpd install as something the common user can wrap their head around, and we even get user confusion around chunking. Plus deflate may provide no benefit, and degrade performance, if the CPU utilization is a greater concern than bandwidth utilization.
