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

The browser API doesn't have a limit on the size of a message, so the
layers below that API should probably support it.
It would be incomplete not to, for sure.

As for why someone would do it? Who knows. Perhaps someone is exploiting
the fact that WS stuff never gets put into a cache for security reasons? Or
perhaps because using the API is easier and better expresses the
application semantics, even if they're not doing web browsing? Any of these
seem reasonable. There is no requirement for WS to include only small
messages...

-=R

On Mon, Feb 24, 2014 at 12:29 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> It there any problem if we mandate that 1 http frame corresponds to 1
> ws frame, and 1 ws frame must reside in 1 http frame? What's the point
> of supporting ws frames that need multiple http frames?
>
> On Mon, Feb 24, 2014 at 12:28 PM, Takeshi Yoshino <tyoshino@google.com>
> 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
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>