Re: HTTP/2 Server Push and solid compression

On Tue, May 21, 2019 at 1:57 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

> > On May 21, 2019, at 1:43 PM, Alan Egerton <eggyal@gmail.com> wrote:
> >
> > On Tue, May 21, 2019 at 6:06 PM Felipe Gasper <felipe@felipegasper.com>
> wrote:
> >> I’m reminded of WebSocket’s “permessage-deflate” extension, which
> includes parameters for controlling the retention of compression context
> from message to message.
> >>
> >> Maybe such an approach for multiple compressed payloads in series would
> effectively eliminate the size difference?
> >
> > But then later messages can be decompressed only after such retained
> > compression context has been discovered from the decompression of
> > earlier messages?  Whilst this could help to increase the compression
> > ratio of subsequent response "bundles" in the same session (at
> > increased server complexity/memory utilization), if used within a
> > "bundle" as proposed would it not present the same sequential access
> > problem that I described for .tar.gz in my previous message (and
> > thereby defeat advantages of HTTP/2 multiplexing)?
>
> Possibly … does h2 multiplexing use a separate compression context for
> each stream, or does it funnel each message through the same context? If
> the former, then I would think it’s a non-issue since streams are processed
> sequentially.
>
>
>
The stream compression contexts are independent - which hurts compression
ratios. However, the WG has not been able to find a satisfactory security
answer to concerns around CRIME like attacks on TLS that sharing attacker
controlled compression streams would enable. Progress on that front would
be great.

-Patrick