- From: Jacob Champion <champion.p@gmail.com>
- Date: Fri, 2 Dec 2016 09:36:38 -0800
- To: ietf-http-wg@w3.org
On 12/02/2016 03:33 AM, Cory Benfield wrote: > I assume that what you mean here is you can’t deploy a H2 *only* > server that also does WS: that is, a server with no HTTP/1.1 stack. > > To which I reply: so what? Last I looked no-one was deploying servers > that can *only* do HTTP/2 except in very specific cases where they > are deliberately seeing the HTTP/2 use-cases (the only two instances > I know of are Apple’s new Push Notification Service and Amazon’s > Alexa API, both of which are HTTP/2 only: presumably they considered > and rejected the use of WS, and it didn’t stop them shipping their > product). > > I don’t think anyone is planning to move to a HTTP/2-only server > stack anytime soon, and we have a whole bunch of servers that have > mature and battle-tested HTTP/1.1 stacks that aren’t going anywhere. > So I’m not really convinced that there’s any demand for H2-only + WS. > Of course, I might be wrong (I’m wrong a lot). I think this ends up being a circular argument. If people rely on both HTTP/2 and WS, but WS requires HTTP/1.1, then they will not demand an HTTP/2-only stack. Likewise with the Amazon and Apple examples: they're going to ship what works; it doesn't necessarily mean the engineers didn't want something different. (Perhaps there are employees watching the list who can chime in?) This is not a server-only thing, either. A conforming WebSocket client has to implement enough of HTTP/1.1 to handle, or at least correctly bail out from, any pre-upgrade shenanigans such as 3xx redirects, 401 authentications, Set-Cookies, etc. (For the record, my background is primarily in the embedded security space, where opportunities to consolidate and reduce software footprint -- and attack surface -- are pretty much always welcomed.) --Jacob
Received on Friday, 2 December 2016 17:37:18 UTC