I think this proposal is a nice shortcut to getting the benefits of websockets on HTTP/2 without redesigning much. It’s something we could probably add to OkHttp and MockWebServer in just a few days. There’s a policy question on what clients should do when a websocket is the first request to a target host. We can build an HTTP/2 connection and then hope to layer websockets on top, or build a bare websockets connection directly and forgo HTTP/2 multiplexing. Browsers might choose to persist settings to inform this decision. Or it would be handy to hint this in the ALPN protocols, though that would require the TLS layer to be aware of this setting! It’s worth explaining what should happen if a naughty client doesn’t attempt a websocket upgrade within the DATA frames of a stream established for that purpose. In particular, a naïve webserver might honor any HTTP/1 request here; that seems like a potential attack vector. Suppose I send this: GET /admin HTTP/1.1 host: localhost Can I can trick a server into treating my request as originating from localhost? The HTTP/2 layer will have already routed the authority for this request but an attacker could contradict that! Nice to see a websockets and HTTP/2 proposal. Thanks! – Jesse
Received on Monday, 16 October 2017 08:35:07 UTC