W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2019

Re: HTTP/2 Server Push and solid compression

From: Felipe Gasper <felipe@felipegasper.com>
Date: Tue, 21 May 2019 13:51:27 -0400
Cc: ietf-http-wg@w3.org
Message-Id: <65908183-BFD4-447D-9F03-E4EB9EB6E0EE@felipegasper.com>
To: Alan Egerton <eggyal@gmail.com>
> 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.

-F
Received on Tuesday, 21 May 2019 17:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC