Re: Questions on Frame Size

Thanks for explaination.

I would be glad if you add some editors notes or whatever on the draft for about it.

I've amended the first commit to change the min frame size so that
it becomes just editorial fixes. I think it's more clear than before.

https://github.com/shigeki/http2-spec/compare/shigeki_20130621

(2013/06/21 11:56), William Chan (ι™ˆζ™Ίζ˜Œ) wrote:
> On Thu, Jun 20, 2013 at 7:40 PM, Shigeki Ohtsu <ohtsu@iij.ad.jp <mailto:ohtsu@iij.ad.jp>> 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.
>
>
>
>

Received on Friday, 21 June 2013 03:53:44 UTC