- From: Greg Wilkins <gregw@intalio.com>
- Date: 2014年11月27日 10:53:01 +1100
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Jason Greene <jason.greene@redhat.com>, Yutaka Hirano <yhirano@google.com>, Andy Green <andy@warmcat.com>, Robert Collins <robertc@robertcollins.net>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NGqJ+=MAkmo-6c3h40RE6TQ=JtC=ftoEdS48qTwDSRY8w@mail.gmail.com>
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.
Received on Wednesday, 26 November 2014 23:53:29 UTC