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

RE: Frame Length Restrictions

From: <K.Morgan@iaea.org>
Date: Sat, 19 Apr 2014 19:08:29 +0000
To: <mnot@mnot.net>, <jpinner@twitter.com>
CC: <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC2011293E9E7@sem001pd.sg.iaea.org>
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)?

If the size limit is _before_ compression, it would kill the compression factor.  The only way to get a reasonable compression factor with frame-by-frame compression is to fill each frame with as much compressed data as possible (see [2]).

On a related note, if you're adding back the two bits, why not let application data use at least 32K?  Using at least 15 bits has advantages for the frame-by-frame compression factor - the max gzip "window bits" is 15 and so is better suited to 32K frames.


[1] See the thread "Transfer-codings, mandatory content-coding support and intermediaries"

[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0156.html

From: mnot@mnot.net [mnot@mnot.net]
Sent: 19 April 2014 08:36
To: Jeff Pinner
Cc: HTTP Working Group
Subject: Re: Frame Length Restrictions

Hi Jeff,

We need to show strong consensus on-list to overturn that, despite being a coin toss. If we want to get this into the next implementation draft, it needs to be demonstrated in the next ~2 days.

I.e., if there's a number of folks who feel this is a no-brainer, great; otherwise, probably not.

Who supports this, and does anyone have a problem with doing it?


On 17 Apr 2014, at 10:34 am, Jeff Pinner <jpinner@twitter.com> wrote:

> I put together a pull request to replace the frame length restriction with an HTTP application layer restriction that I would like the working group to consider.
> https://github.com/http2/http2-spec/pull/456
> Of particular note is that this is in contrast to a previous decision made by the working group (albeit by coin toss in Seattle) which can be found
> https://github.com/http2/http2-spec/issues/260
> With the addition of padding to the framing layer, I believe it is preferable to implement the frame length requirement at the HTTP layer to allow intermediaries to pad frames without running into frame length restrictions.
> Thanks!
> - Jeff

Mark Nottingham   http://www.mnot.net/

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Saturday, 19 April 2014 19:09:08 UTC

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