Paul Querna wrote:
> 
> Yes, write a Varied header to 'hash' plugin API for mod_cache.
> 
> I would write little lua scriptlets that map user agents to two
> buckets: supports gzip, doesnt support gzip.  store the thing in
> mod_cache only twice, instead of once for every user agent.

This doesn't solve the problem of each-and-every downstream proxy
cache storing an excessively large number of copies.  Even if we
strip down comments from the fields before choosing cache entries,
Mozilla's many versions of Mozilla/2.0.3 and Gecko/20090731 tags
are going to continue to proliferate copies.

I'm suggesting that this might need to be 'invisibly' handled, not
using Vary:, but by any proxy clever enough to detect the non-conforming
browser to then strip the request to deflate/gzip.  At that point, the
choice-of-two becomes obvious to all proxies and back end servers with
this knowledge.  If this is unknown to an earlier proxy, the client
could get the broken deflate/gzip content, but that seems unavoidable.

Honestly, I can't see a way to honor HTTP/1.1 cache negotiation goals
while minimizing cache pollution.

I did consider a module (lua or otherwise) that would 'interfere' in
the initial quick handler phase just to work out broken user agents,
rather than carry the entire weight of setenvif/headers to the quick
handler phase.


Reply via email to