Re: HTTP/2 and Websockets

>
> So failing that, our best solution is to pick whatever hack we have to
> sooner rather than later so that we can at least hammer in special case
> handling for websockets into intermediaries and hope that no new semantics
> emerge.

+1



On Thu, Nov 27, 2014 at 8:53 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 26 November 2014 at 08:25, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Sadly, since it was something that a few of us in the WG were pushing
>> for, as it would have allowed intermediaries without knowledge of protocols
>> to do what was right for them.
>> That is why I truly hope that the WS extension happens (and quickly)--
>> I'd love to see loadbalancers relieved of having to introspect into the
>> data further than the HTTP2 frame layer in order to figure out how to deal
>> with it reasonably.
>>
>
> +1
>
> Non-constructive comments from me are that this is simply way too late in
> the process for this to be considered and I suspect that with the framing
> layer we have given ourselves, all possible solutions will now be pretty
> ugly.
>
> It comes down to a choice between:
>
> a) defining new frame types for WS.   Which is going to require very
> explicit support from intermediaries (imagine if we had to do that in TCP
> for every new protocol!).
>
> b) reusing the existing HEADER/DATA frames, but they miss some useful
> semantics and have been so conflated with HTTP semantics that we are back
> to websockets pretending to be HTTP - which is exactly the sort of protocol
> mis-use that we were chartered to resolve!
>
> Currently I can't pick between these two ugly ducklings.       We long ago
> missed the opportunity of coming up with a truly multiple protocol web
> framing layer that would support diverse semantics such as HTTP, websocket
> and whatever the future may bring.    So failing that, our best solution is
> to pick whatever hack we have to sooner rather than later so that we can at
> least hammer in special case handling for websockets into intermediaries
> and hope that no new semantics emerge.
>
> Will try to find the time in the next week to experiment with some of the
> options, so we can be a bit more constructive about which we prefer.
>
> regards
>
>
> --
> Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>