Re: Questions on Frame Size

[William Chan (陈智昌) <[e-mail]>]

On Thu, Jun 20, 2013 at 7:40 PM, Shigeki Ohtsu <[e-mail]> wrote:

> It seems that everyone agreed max 16K in HTTP but is not sure for use of
> 64K now.
>
> I think it is a bad idea to require for all implementers to suport 64K
> frame size because
> it is too early to discuss future extensions for non-HTTP protocols.
>

I think this argument is invalid. I would find it valid to say that this is
unnecessary complexity (having a larger max frame size at the framing
layer) since that's for non-HTTP protocols and it's too early to discuss
them. But if your implementation only going to support HTTP semantics
anyway and plans to choke if someone tries to send a frame for a non-HTTP
application layer protocol, then I don't think there's any additional
implementation burden here.


>
> I've just made two commits for
>
> 1. change the requirement of min size of frame to 8K as previous one
> (maybe 16K is okay)
> 2. write max frame size of 16K explicity when carrying HTTP
>
> https://github.com/shigeki/**http2-spec/compare/shigeki_**20130621<https://github.com/shigeki/http2-spec/compare/shigeki_20130621>
>
> If this is accepted, I will submit the PR.
>
> Regards,
>
>
> (2013/06/21 10:14), David Morris wrote:
>
>>
>>
>> On Fri, 21 Jun 2013, Amos Jeffries wrote:
>>
>>  Which implies that server-push is a different protocol to HTTP already.
>>>
>>
>> Different from 1.1, but a new feature of 2.0
>>
>>
>>  IIRC: the 64K limit is for next-generation requirements of systems
>>> running
>>> HTTP at TB speeds. Allowing new frames to be added for those larger line
>>> rates
>>> is very useful given they are already on the horizon and HTTP/2.0 has
>>> long
>>> lifetime ahead.
>>>
>>
>> In the SF Interim, we agreed to 64K/16K (frame/vs HTTP) to allow for the
>> larger frame required to establish a TLS connection without added round
>> trips because the initial TLS setup exceeded a single frame.
>>
>>
>
>