Re: HTTP/2 and Websockets

I'm not entirely sure yet, but it could be as simple as using CONNECT with
a ws[s]:// URI. That might seem crazy, but acceptance of that would
indicate that the intermediary supported the protocol, it would therefore
be hop by hop with an option at each hop to fall back to a non-multiplexed
form (i.e., CONNECT in the standard form with all the baggage of the two
layers), and you could even steal flags for the TBC and bin/text bits.

On Tue, Nov 25, 2014, 17:44 Andy Green <andy@warmcat.com> wrote:

>
>
> 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
> >> >>
> >>
> >>
>
>