- From: Roberto Peon <grmocg@gmail.com>
- Date: Wed, 19 Jun 2013 23:44:58 -0700
- To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNd5Z3VgK6BBF6DJJdVdkdRj9bjdmKsKVcR_+cc3rSyrkQ@mail.gmail.com>
The spec is in flux w.r.t. layering, where this will be clarified. Right now, as I understand it, however, the intent is that HTTP will be limited to 16k frame sizes, and anything larger would get you a protocol error or similar. -=R 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 06:45:28 UTC