Re: #445: Transfer-codings

I've started keeping track of my T-E proposal in github[1], and have been
attempting to come up with ways to address people's concerns.

* The easy issue was the size of identifiers, which I've reduced to 8 bits
in my current text -- i.e. 256 possible values. The worst case commitment
as a result is 256 rank values, which I've also reduced to 8 bits -- so 256
bytes. However as I and others have pointed out, the minimum commitment as
a result of this proposal is nil, and a reasonable realistic value is
probably 1-2 bytes per connection.

* I wanted to keep the rank because I'd like the ability for someone to
change their mind about an encoding. I would be happy with a single bit, if
I could come up with a way to pack it into the settings frame that doesn't
make me feel yucky. The case I'm addressing is a proxy that, having
advertised support for gzip, finds itself being zip-bombed (or possibly
just under an unexpectedly high load) and decides to stop receiving gzip
payloads from downstream.

* I've not included any suggestion of how people could or should use rank
values to determine a preferred encoding. I don't think that's a problem
though; RFC 2703 and RFC 2295/2296 exist if people really need
inspiration. It could also go away if rank is reduced to a single bit.

* An issue I'd like to address is the ability to specify multiple
encodings on a single frame. This could be done by either expanding the
proposed Encoding field in the DATA frame to some fixed multiple (e.g. 4
encodings), or with a length-prefixed or a null-terminated (er,
identity-terminated) list.

* The big issue I'm still trying to get straight in my head is the
objection that compression can reduce security when applied by part of the
transport chain that doesn't have full knowledge of the properties of the
data. The server has no way of signalling that intermediaries shouldn't
apply compression.

   My thoughts on this are that end-to-end encryption is meant to solve
that problem, by making it very hard for intermediaries to modify your
data. Also: the known compression-based vulnerabilities are based on
sharing a single compression context between secret and public data; since
this proposal uses a unique context per compressed frame, and since it's
probably not likely that intermediaries would bother coalescing data
frames, all the server has to do is send the secret and public bits in
separate frames. Not a bullet-proof solution, but not unreasonable.

Does anyone else have a concern that I've not addressed? Or possibly one
that got lost in the volume of the discussion?


[1]:
https://github.com/phluid61/http2-spec/compare/445-transfer-codings#files_bucket



-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/