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