Re: #445: Transfer-codings

On Apr 12, 2014 1:18 AM, "Roland Zink" <roland@zinks.de> wrote:
>
> On 11.04.2014 01:48, Roberto Peon wrote:
>>
>>
>>
>>
>> On Wed, Apr 9, 2014 at 11:16 PM, Matthew Kerwin <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?
>

I think the argument here is that the commitment for C-E only applies go
the client*, so light-weight proxies can remain light-weight.

*apart from 1.1<->2 gateways, apparently