Re: HTTP/2 and Websockets

That is what you called "super-inefficient" (HEADERS + DATAs).

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
>