Re: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)

[Takeshi Yoshino <[e-mail]>]

On Tue, Feb 25, 2014 at 3:59 AM, Roberto Peon <[e-mail]> wrote:

> As I understand it:
>
> If the previous DATA frame on the stream included END_SEGMENT, and the
> current DATA frame on the stream includes END_SEGMENT, then the HTTP2 frame
> length == the websocket frame length.
> This is extremely likely to be the common case.
>
> If the websocket frame needs to be broken up (generally only because it
> has a large payload), then some other signaling of the frame length is
> necessary, e.g. by using an HTTP/2 HEADERS frame with content-length key.
>  -=R
>
>
> On Mon, Feb 24, 2014 at 10:43 AM, Joakim Erdfelt <[e-mail]>wrote:
>
>> Let me see if I grok this entirely...
>>
>> You are saying that HTTP/2.0 HEADERS has a 14 bit value already.
>> You would like to utilize this existing 14 bit value to represent
>> websocket payload data.
>>
>
Yes. Using the 14 bit length combined with the END_SEGMENT signal, we can
represent a block by sequence of HTTP/2.0 DATA frames.

As Roberto said, the simplest case is (for simplicity, padding in DATA
frames is assumed to be 0):

DATA(length=n, END_SEGMENT(2nd bit in flags)=true, Data=payload data of n
bytes)

Where Data field contains one byte to represent FIN, RSV1-3 and opcode. Or,
instead we can send HEADERS before the DATA which contains FIN, RSV1-3 and
opcode header since they would compress well compared to length header.

If payload is large, a sequence

DATA(length=s_0, END_SEGMENT=false, Data=payload data of s_0 bytes),
DATA(length=s_1, END_SEGMENT=false, Data=payload data of s_1 bytes),
...
DATA(length=s_n, END_SEGMENT=true, Data=payload data of s_n bytes)

represents the original frame. Where the first one byte in the
concatenation of Data fields has FIN, RSV1-3 and opcode, or instead we can
send HEADERS before the sequence of DATAs which contains FIN, RSV1-3 and
opcode.


>  You would like to avoid having to adjust or supplement HTTP/2.0 HEADERS
>> just for WebSocket behaviors.
>>
>
Yes. I'm trying to use what we have now as-is.


> You are indicating that this 14 bit value is not a 1 to 1 representation
>> of "original WebSocket frame size" as determined by various APIs or
>> extensions before hitting the HTTP/2.0 layer.
>>
>
Right


>  You hint at the behavior of large (over 14 bit length) "original
>> WebSocket frames" being likely sent in multiple HTTP/2.0 DATA/END_SEGMENT
>> portions.
>>
>
Right


>  Wouldn't this also mean that any "original WebSocket frame" length
>> information not being present on the receiving side. right?
>>
>
 Not present on receiving the first DATA, but will be revealed on receiving
the length header of the last DATA frame (with END_SEGMENT on).


>  The receiving side would just see HTTP/2.0 DATA/END_SEGMENT with some
>> indicator that the DATA is for WebSocket, right?
>>
>
I don't quite understand this question. It's already known that DATAs
contain WebSocket traffic by ":scheme" in the opening handshake.


> The receiving side would never see the "original WebSocket frame" as this
>> information is now lost.  Is that correct?
>>
>
END_SEGMENT tells where the boundary of the frames was.


>  Instead you have HTTP/2.0 DATA length header for WebSocket payload data,
>> along with an END_SEGMENT indicating the separation between WebSocket
>> messages.
>>
>
That depends on another topic. If we separate messages with END_SEGMENT,
then yes. If we separate frames with END_SEGMENT, then no.

I'd like to get consensus on that length header in HTTP/2.0 DATA frame is
sufficient. It's a topic independent from whether we preserve frame
boundary or not.


>
>>
>> --
>> Joakim Erdfelt <[e-mail]>
>> webtide.com <http://www.webtide.com/> - intalio.com/jetty
>> Expert advice, services and support from from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>>
>> On Mon, Feb 24, 2014 at 11:28 AM, Takeshi Yoshino <[e-mail]>wrote:
>>
>>> Thanks all for your comments.
>>>
>>> First, please note that I wanted to discuss the question in the context
>>> of WS/HTTP/2.0 layering. Not about redesign of RFC 6455 itself.
>>>
>>> I asked this question since the length header is the biggest field when
>>> encoded into HTTP/2.0 HEADERS format. Whether we can eliminate it or not in
>>> WS/HTTP/2.0 is one of the most important points to evaluate the plans
>>> employing HTTP/2.0 HEADERS.
>>>
>>> Though the ranges the length headers represent differ (HTTP/2.0: 14 bit,
>>> WS length format: 63 bit), it seems everyone can live without a header of
>>> "original WebSocket frame size".
>>>
>>> Please reply to this post if you have any objection, but please don't
>>> write objection to use of HTTP/2.0 HEADERS itself in this thread.
>>>
>>> Thanks
>>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>
[1] http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-00