- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 21 Jun 2013 11:10:29 -0700
- To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I've made a few changes. Let me know if the current spec is somehow inadequate. On 20 June 2013 20:53, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote: > 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 18:10:56 UTC