Antwort: Re: Antwort: Re: Antwort: Re: Antwort: [Mod_gzip] Vary: header and mod_gzip

Hi Anil,

>> There is a very powerful configuration rule, the
>> "mod_gzip_item_include reqheader".
>> You can simply use _every_ HTTP header you like
>> to make to compression of mod_gzip depending on it.
>
> Thanks for the explanation Michael - so ideally, the
> Vary header that mod_gzip emits should be constructed
> from the request headers it touches using these rules.
>
> Forgive me if I've missed the point of the discussions,
> but is this the general consensus so far?

I think so. Currently my main issues are these:

a) How would one implement a function to parse the
   mod_gzip rules configuration to collect the set
   of all potential HTTP header names to be added
   to the "Vary:" header, i. e. all the "reqheader"
   rules plus "Accept-Encoding"?
   "Touching" would be a method to find this out,
   but not as long as mod_gzip doesn't even touch
   rules if it has found some earlier reason to
   decline compressing a response, which may _not_
   fire in other cases. The current implementation
   of the mod_gzip filter rules checker doesn't
   work as it would have to if it needs to find out
   which rule classes the result may depend on.

   I wish I knew more about the Apache internal
   architecture, like about the data structures for
   storing configuration knowledge. There _may_ be
   a chance to compute the list of relevant HTTP
   headers not during mod_gzip execution but already
   during Apache startup, which would certainly re-
   duce the additional operational overhead for
   mod_gzip to compute this information.

b) Are there situations where mod_gzip can find out
   that the content will never vary, as to not send
   a "Vary" header in these cases and make life
   easier for the proxy?
   I think this can only be done for the 'declining'
   path of mod_gzip, as there can never be a case
   where mod_gzip will _always_ compress content.

   By the way, the current patch 1.3.19.1b is sen-
   ding the "Vary:" header only if content has been
   gzipped. This may result in the proxy to store
   to uncompressed content if by bad luck the first
   request for this ressource would ask for uncom-
   pressed content, and as the proxy has no clue
   about available alternatives it would never ask
   for 'better quality' again, but always serve
   this uncompressed version.
   Unfortunatly, modifying the HTTP headers even
   if mod_gzip did _not_ change the content isn't
   a no-brainer IMHO, as the current strategy of
   mod_gzip is to simply exit if nothing has to be
   done and tell Apache it didn't do anything by
   some return code. If now even _declining_ to
   compress a request would mean that mod_gzip had
   to modify the HTTP headers this would have a lot
   of consequences for the current program archi-
   tecture. This would require someone to under-
   stand the Apache structure better than I do.

c) Are there situations where mod_gzip can find out
   that some rules are irrelevant, as to omit the
   HTTP headers from the "Vary:" header names list?
   Maybe a "nice to have" only, but might increase
   the efficiency of the combined effect of compres-
   sion and caching, so keep it on the list.

To sum it up: mod_gzip ought to send "as many Vary:
fields as necessary but as few as possible".
Which might prove to be be a challenging algorithmic
task as well as a non-trivial C coding task.

Greetings, Michael
Received on Wed Aug 28 2002 - 07:57:20 MDT