W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #445: Transfer-codings

From: Roland Zink <roland@zinks.de>
Date: Sat, 12 Apr 2014 18:09:18 +0200
Message-ID: <5349652E.6060300@zinks.de>
To: Matthew Kerwin <matthew@kerwin.net.au>
CC: ietf-http-wg@w3.org
On 11.04.2014 23:49, Matthew Kerwin wrote:
>
> On Apr 12, 2014 1:18 AM, "Roland Zink" <roland@zinks.de 
> <mailto: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 <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?
> >
>
> 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
>
I think this argument not really holds. When gzip T-E is mandated like 
now C-E then light-weight proxies don't need to touch the compression 
and can forward the received bytes unmodified. The transferred data 
bytes could be the same in both cases. This would be different when 
support is optional and the next hop doesn't support it, or the 
compression is tied to a connection instead of a stream or the proxy 
want to look into the content.
Received on Saturday, 12 April 2014 16:09:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC