Re: Support for gzip at the server #424

It's unfortunate, but I agree that given the interop issues, I don't think
we can require this.

I haven't thought about it deeply, but perhaps we can opt-in using the
SETTINGS and HTTP2-Settings headers. Explicit server declaration of
support. I haven't gamed it out completely in my head yet as to whether or
not that would create other obstacles and whether or not it's better than
application specific knowledge (e.g. JS shipped from server to client).


On Fri, Mar 14, 2014 at 2:21 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 14 March 2014 14:15, Michael Sweet <msweet@apple.com> wrote:
> > The client is generally rasterizing pages of content for the printer at
> some
> > agreed upon resolution, bit depth, and color space.  This raster data is
> > typically already compressed with a simple algorithm such as PackBits
> > (run-length encoding) and is thus already variable-length per page with
> no
> > way to know ahead of time how large it will be.  Add gzip to the mix and
> you
> > *really* don't know what the final length will be.
>
> This seems like a case of "I know the server capabilities well enough
> to do this".  I'm not sure that we could safely do the same thing for
> every HTTP client in existence.
>
>