W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-vkrasnov-h2-compression-dictionaries-01.txt

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 3 Nov 2016 12:55:37 +1000
Message-ID: <CACweHND+E7D0oKR+_2sKVOqrAwx_hQW9Z=MAmDFGfbqEzR4xGQ@mail.gmail.com>
To: vlad@cloudflare.com, Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Just chiming in without necessarily attaching to a particular thread of
discussion: I'm quite probably being thick here, but isn't there a problem
(of the abstraction/encapsulation flavour) with making a content-encoding
dependent on values sent at the transport layer? I think I'm just
reiterating what Martin was saying, but in a more vague and incoherent way.

If we're discussing compression parameters/algorithms/dictionaries/etc. at
the transport layer, shouldn't the entirety of the compression happen at
the transport layer? Thus making it like HTTP/2's new version of TE.

And if so, isn't transport layer compression a Bad Thing™? Because – thanks
to the wonder of abstraction – the transport machinery doesn't
(necessarily) know the provenance of the bytes it's compressing (thus
potentially allowing sensitive and attacker-controlled data to be
compressed in the same context – i.e. BREACH.)

So we bounce it up the stack to the application, which has a much better
chance of knowing who authored what bytes. And thus we end up back at

If it's tied to content-encoding, it should be **entirely** contained in
the semantic layer – headers and payload entities. Isn't that what SDCH is?

If it's pushed down to the transport layer, isn't it just an even less safe
version of draft-kerwin-http2-encoded-data? (I said no shared compression
context between different frames, this is about sharing contexts between
completely different *streams*!)

I'm not entirely sure what new thing this particular proposal brings to the

  Matthew Kerwin
Received on Thursday, 3 November 2016 02:56:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 02:56:14 UTC