- From: Andy Green <andy@warmcat.com>
- Date: Thu, 27 Nov 2014 08:02:47 +0800
- To: Greg Wilkins <gregw@intalio.com>,Roberto Peon <grmocg@gmail.com>
- CC: Martin Thomson <martin.thomson@gmail.com>,Jason Greene <jason.greene@redhat.com>,Yutaka Hirano <yhirano@google.com>,Robert Collins <robertc@robertcollins.net>,Amos Jeffries <squid3@treenet.co.nz>,HTTP Working Group <ietf-http-wg@w3.org>
On 27 November 2014 07:53:01 GMT+08:00, 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 Hmmmm it's late in the process to consider it because everybody put off working on it! It's not a new observation this http2 stuff will be carrying ws traffic and clearly Hirano-san has been trying to move it on for a long while. >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! No... for http2 it's helpful to think about this as a generic stream upgrade to opaque data in DATA issue, not particularly websockets. -Andy >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
Received on Thursday, 27 November 2014 00:03:23 UTC