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.