- From: Andy Green <andy@warmcat.com>
- Date: Wed, 26 Nov 2014 09:43:52 +0800
- To: Yutaka Hirano <yhirano@google.com>
- CC: Martin Thomson <martin.thomson@gmail.com>,Jason Greene <jason.greene@redhat.com>,Robert Collins <robertc@robertcollins.net>,Amos Jeffries <squid3@treenet.co.nz>,HTTP Working Group <ietf-http-wg@w3.org>
On 26 November 2014 09:39:37 GMT+08:00, Yutaka Hirano <yhirano@google.com> wrote: >Sorry that the proposal was updated in another place: >https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md >I forgot to link the document. > >In the github document, a WS message is encoded to HEADERS + DATAs. OK... then I guess we could agree, calling it super inefficient was being kind ^^ What we're talking about now, HEADERS to make the upgrade one time and then pure DATA representing one ws frame, would be perfect. But I don't know how to get rid of the WS_FLAGS byte in the payload right now to get there. -Andy >On Wed, Nov 26, 2014 at 10:35 AM, Andy Green <andy@warmcat.com> wrote: > >> >> >> On 26 November 2014 09:32:48 GMT+08:00, Yutaka Hirano ><yhirano@google.com> >> wrote: >> >That is what you called "super-inefficient" (HEADERS + DATAs). >> >> Sorry maybe I misunderstood your writeup. It sounded like it wanted >to >> send HEADERS + DATA per frame. >> >> -Andy >> >> >On Wed, Nov 26, 2014 at 10:28 AM, Andy Green <andy@warmcat.com> >wrote: >> > >> >> >> >> >> >> On 26 November 2014 05:17:41 GMT+08:00, Martin Thomson < >> >> martin.thomson@gmail.com> wrote: >> >> >On 25 November 2014 at 11:55, Jason Greene ><jason.greene@redhat.com> >> >> >wrote: >> >> >> >> >> >> What is the benefit to preventing reframing? The negative of >such >> >a >> >> >restriction is that intermediaries will be unable to utilize >their >> >> >knowledge of their network topology to improve performance. >> >> > >> >> > >> >> >It would appear that Yukata and Andy want to use HTTP/2 frame >> >> >boundaries as the basis for WS frame boundaries. That implies >that >> >> >you need to prevent blind reframing. Since reframing is an >inherent >> >> >part of HTTP/2, I note that this would be unwise. (And for more >> >than >> >> >just the reasons you describe.) >> >> >> >> Nah. >> >> >> >> Like http2 framing, ws framing is perfectly fungible with no >> >guarantees >> >> that what was sent is what is received, other than for the payload >to >> >be >> >> the right total amount eventually and in the right order. Ws is >also >> >fine >> >> with frame fragmentation during transport as much as you like. >> >> >> >> Since in the scheme described the DATA frame is the ws frame, >> >fragmenting >> >> the DATA at the same time fragments the ws frame which is fine. >> >> >> >> The only problem is we stuck the ws frame flags byte at the start >of >> >the >> >> DATA / ws frame. If that's how it is, then the fragmentation >action >> >has to >> >> understand the stream upgraded to ws and manage adding / removing >> >that >> >> extra byte when splitting or combining DATA. >> >> >> >> If you have a suggestion for getting rid of the extra byte and >just >> >having >> >> pure ws payload in the DATA, that would make it completely >> >transparent for >> >> http2 fragmentation. >> >> >> >> -Andy >> >> >> >>
Received on Wednesday, 26 November 2014 01:44:28 UTC