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

Re: Questions on Frame Size

From: James M Snell <jasnell@gmail.com>
Date: Thu, 20 Jun 2013 09:29:33 -0700
Message-ID: <CABP7RbeS7zeVnOM7R0mcUe+t-M+Ta3GVZr+1A3gSjY8QqCOgzQ@mail.gmail.com>
To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
My understanding is...

When PUSH_PROMISE is used for HTTP, then yes, it would be limited to 16k.
When PUSH_PROMISE is used for any protocol other than HTTP, it could
be up to 64k.

We are defining the Framing Layer separately from the HTTP Layer in
order to allow other protocols to be built on top of the framing layer
at some point.

On Wed, Jun 19, 2013 at 10:32 PM, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote:
> Hi,
> The issues about frame size were discussed and might had some
> agreements at SF interium but please let me ask some questions on the
> current spec of "3.3.2 Frame Size" which is updated by
> https://github.com/http2/http2-spec/commit/fd703b572cfc527582c0716e59f2c4044ae195a8
> 1. "For instance, individual DATA and HEADERS frames used to express
> HTTP request and response messages (see Section 4) are not permitted
> to exceed 16,383 octets of payload."
> PUSH_PROMISE is not listed.
> Is the data size of PUSH_PROMISE also limited to 16K or is it exceptional
> for some reason?
> 2. "The absolute maximum amount of payload data any individual frame
>  can contain is 65,535 octets. All implementations SHOULD be capable
>  of receiving and minimally processing frames up to this size."
> If PUSH_PROMISE has a 16K limit, the max frame size is still 64K,
> however, any other frames besides DATA, HEADERS and PUSH_PROMISE
> are only several octets at most.
> Is it for the future extension not to change the frame length to 14bit?
> If so, why the spec requires all implementations to support the 64K frame
>  size only for the future extension?
> Regards,
Received on Thursday, 20 June 2013 16:30:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC