-----Oorspronkelijk bericht-----
Van: Martin Stjernholm [mailto:<mast[at]roxen.com>]
Verzonden: Wednesday, January 21, 2009 11:14 PM
Aan: Arjan van Staalduijnen
CC: <roxen[at]roxen.com>; Stephen R. van den Berg; Martin Jonsson
Onderwerp: Re: [PATCH 14/17] New module: gzip-on-the-fly
"Arjan van Staalduijnen" <<Arjan.van.Staalduijnen[at]rtl.nl>> 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.
__________________________________________________________
|