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

[Zhong Yu <[e-mail]>]

On Mon, Feb 24, 2014 at 12:43 PM, 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.
> You would like to avoid having to adjust or supplement HTTP/2.0 HEADERS just
> for WebSocket behaviors.
> 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

I never understand why APIs expose the concept of frames. It's like
TCP APIs exposing the concept of TCP segments.

> before hitting the HTTP/2.0 layer.
> 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.
>
> Wouldn't this also mean that any "original WebSocket frame" length
> information not being present on the receiving side. right?
> The receiving side would just see HTTP/2.0 DATA/END_SEGMENT with some
> indicator that the DATA is for WebSocket, right?
> The receiving side would never see the "original WebSocket frame" as this
> information is now lost.  Is that correct?
> Instead you have HTTP/2.0 DATA length header for WebSocket payload data,
> along with an END_SEGMENT indicating the separation between WebSocket
> messages.
>
>
> --
> Joakim Erdfelt <[e-mail]>
> 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
>
>