- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 21 Nov 2014 10:32:31 -0600
- To: Yutaka Hirano <yhirano@google.com>
- Cc: Robert Collins <robertc@robertcollins.net>, Andy Green <andy@warmcat.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
> On Nov 21, 2014, at 3:08 AM, Yutaka Hirano <yhirano@google.com> wrote: > > On Fri, Nov 21, 2014 at 5:44 PM, Robert Collins <robertc@robertcollins.net> wrote: > On 21 November 2014 20:03, Yutaka Hirano <yhirano@google.com> wrote: > > > > > I don't like the idea of using the existing DATA frame. > > > > 1. An intermediary must flush data when it sees an end of message (FIN). > > But intermediaries won't be buffering: they'll be forwarding as soon > as they can, since h2 is being established from the get-go as an > interactive protocol. > > Hmm... Is that specified? > Are such buffering proxies prohibited explicitly? Intermediaries are likely to do some form of buffering because: - Each hop can have its own frame size and flow control limits - Environmental factors including capacity of the wire and the server vary how flow control will behave and how large a frame can/will be at each hop - Intermediaries can coalesce multiple clients on the same connection forcing some massaging of the individual streams On the other hand, what you say above is true, that it is in the intermediary’s interest to get rid of the data as soon as possible. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 21 November 2014 16:34:20 UTC