-----Oorspronkelijk bericht----- Van: Martin Stjernholm [mailto:[email protected]] Verzonden: Wednesday, January 21, 2009 11:14 PM Aan: Arjan van Staalduijnen CC: [email protected]; Stephen R. van den Berg; Martin Jonsson Onderwerp: Re: [PATCH 14/17] New module: gzip-on-the-fly
"Arjan van Staalduijnen" <[email protected]> wrote: > Here are some assorted thoughts of mine on the subject: === snip === > o A vary callback is not really a good way to go - we don't want to > risk splitting the cache hits into uncompressed/compress/gzip/etc. > Better choose one compression method and always use it (when > compression at all is considered). Maybe one can make add > uncompression to be able to send a cached response to a client that > doesn't support the compression method, but otoh such clients might > be so few that it's not really worth the bother. I agree different version should be kept low as possible, thus not having separate entries for all of 'compress', 'deflate', 'gzip', 'x-gzip' and 'no compression' (any more flavors?). Basically my guess is more than 95% nowadays would match the gzip version. The vary_callback mechanism was the only thing available to guarantee proper responses to non-supportive browsers, so in my opinion it is a requirement. The x-gzip vs gzip problem was something I bumped in to around 2001, 2002, when I was using an earlier module doing delayed 'on the fly' gzip compression for popular content (using a create_process for forking an external gzip binary - duh). I don't know how frequent requests are still being done using x-gzip, but I guess it is not a lot anymore... To guarantee a proper response (x-gzip browser do mess up 'content-encoding: gzip' responses) it could be a choice to support x-gzip as a separate version, or to park it under 'no compression support'. Another possibility could be, since the only difference is their output Content-Encoding header, to make that header dependant on Accept-Encoding containing x-gzip or gzip. That is not possible in current protocol cache code, currently leaving a vary_callback for the only option. AvS __________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________
