Re: #445: Transfer-codings

On 11.04.2014 01:48, Roberto Peon wrote:
>
>
>
> On Wed, Apr 9, 2014 at 11:16 PM, Matthew Kerwin <matthew@kerwin.net.au 
> <mailto:matthew@kerwin.net.au>> wrote:
>
>     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.
>
>
> Actually, the size committment for any receiver of something which 
> uses T-E would be the minimum size of the encoding context. For gzip, 
> this is decided by the sender and is not trivial, and thus provides 
> for an interesting DoS vector against the receiver.
> This would completely throw out the things we've done in HTTP/2 to 
> ensure that the receiver controls the size of the amount of memory it 
> needs to use. That seems silly at best.

This seems to be a property of gzip, so isn't this the same for C-E?