[EMAIL PROTECTED] wrote:
What sort of testing did you do in those few hours?
That's why I posted it, to get some more input.
If I could play devil's advocate for a moment... my concern would be that you haven't considered certain scenarios that won't work with this patch.
Most of the cache code has corner cases where it falls apart.
Did you test a scenario whereby the COS ( Content Origin Server ) is actually trying to "Vary:" the content based on "User-Agent:" regardless of the "Accept-Encoding:" value?
Then you shouldn't override User-Agent. I assume that the admin knows alot about the COS. If not, then these options should not be used. I am targeting the "reverse" cache where the admin know alot about the origin.
COS has sent 2 totally different responses based on whether 'User-Agent' was MSIE or NETSCAPE. Both of those responses were compressed ( Content-Encoding: gzip ) and they should have been stored as 2 different ( compressed ) 'variants' for the same response based on ( non-overriden ) actual value of "User-Agent" field.
In this case, you could use SetEnvIf to set User-Agent to NETSCAPE or MSIE based on the actual value. If you know this much about the content, then its trivial. If not, don't override anything.
It's like CacheIgnoreHeaders. It breaks RFC's, but there are cases where this is A Good Thing. In the general case, as you pointed out, it is not.
-- Brian Akins Lead Systems Engineer CNN Internet Technologies
