On 05/16/11 18:35, Michael Snoyman wrote:

On Mon, May 16, 2011 at 11:23 AM, Erik de Castro Lopo <mle+hs@mega-nerd.com> wrote:
  c) Modify the Network.Http.Enumerator.http function so that
   de-chunking/gunzipping is optional.

I would guess that (c) is really the best option, though I'm guessing you shied away from it because it involved more substantial changes to http-enumerator. Maybe we should consider adding an extra httpAdvanced function that takes additional settings, such as whether or not to automatically de-chunk/de-gzip. I wouldn't be surprised if we come up with more such cases in the future.

Well, one whacky-but-nifty related idea I've had is that if you're outputting a gzip'ed page, but you've got some expensive chunk of the page in the middle that you've cached, it is technically possible to actually cache that chunk pre-gzip'ed and output it directly into the gzip'ed output, or at the output layer, de-gzip it for a non-gzip'ed page if necessary, which since that is more rare might be a win. You can do this because at any time you can flush a gzip stream and simply start sending another one, though you lose your dictionary when you do that so you wouldn't want to do this below some cutoff size.

Whether or not this is ever a good idea, I don't know; I've never had anything like the infrastructure it would take to benchmark it. It could be anything from a surprisingly cool addition that few other frameworks could compete with, to a net loss. (Or both, depending on how it is used.)