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

Re: Frame Length Restrictions

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 22 Apr 2014 19:20:02 +1000
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1621F1CC-D280-4A86-A9F8-2BB6F3D08916@mnot.net>
To: Jeff Pinner <jpinner@twitter.com>
Hey Jeff,

It feels like this conversation isn't done yet, and we're very much overdue for the next implementation draft. So, let's continue, but not block on it, OK?

Thanks,


On 22 Apr 2014, at 5:48 pm, Jeff Pinner <jpinner@twitter.com> wrote:

> On Mon, Apr 21, 2014 at 9:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Not so.
> 
> Rather than 8 bytes of overhead every 2^14-1 bytes, you have 8 bytes
> of overhead every 2^14-9 (or 8, which is be sufficient).  If that's a
> problem, then any sort of framing overhead is a problem.
> 
> I don't think I follow. Are you saying that the overhead of always splitting frames is negligible so it's ok to always split frames in order to not have a discontinuity in padding?
> 
> That seems to be saying that implementations that don't always split frames could have an issue but they should just "do the right thing" instead of forcing it by calling out the restriction in the protocol itself.
> 
> If that is the argument (and I'm not saying it is) then it seems antithesis to restricting the frame length in the first place. Arguably implementations that care about responsiveness should "do the right thing" and restrict the data payloads instead of having the protocol force them to do so at the expense of applications that either do not multiplex or do not care about interactivity.
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 22 April 2014 09:32:18 UTC

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