- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 20 Apr 2014 18:07:27 +1200
- To: ietf-http-wg@w3.org
On 20/04/2014 10:07 a.m., Patrick McManus wrote: > On Sat, Apr 19, 2014 at 3:08 PM, K.Morgan wrote: > >> Regarding this part of the pull request... >> >> The application data in DATA frames ... MUST NOT exceed 2^14-1 (16,383) >> octets in length. An endpoint MUST treat the receipt of a larger frame as a >> FRAME_SIZE_ERROR error ... >> >> ...and the pending pending re-introduction of gzip compression at the >> frame layer [1]. >> >> >> >> Is the size limit for application data _before_ or _after_ compression >> (specifically transfer layer compression)? >> >> >> > The size of the DATA frame is capped at 16KB in order to facilitate > effective multiplexing and prioritization - it only the on-the-wire size > that matters. > There is also a trade-off here between good compression factor and reducing memory overheads in the recipient to keep in mind here. An abuser can send far less (exponentially less?) payload in compressed 16K chunk than they can in a 32K chunk. Maybe the 14-bit/15-bit compression difference is an added bonus on protecting against these kinds of abuses. Amos
Received on Sunday, 20 April 2014 06:07:59 UTC