- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 07 Feb 2013 15:50:12 +1300
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- CC: ietf-http-wg@w3.org
On 7/02/2013 3:23 p.m., Ilari Liusvaara wrote: > On Thu, Feb 07, 2013 at 02:21:21PM +1300, Amos Jeffries wrote: >> Thank you. I was loosing hope of finding these in the TLS RFC's. > (That was just from memory, but I verified it by dumping a TLS > ClientHello packet). > >> So the relevant magic for TLS is F=0,C=0, type=0x16, top byte of the >> length field being non-0x0. Meaning we can distinguish it easily >> from WebSockets and HTTP/2 client. Good news there. > Note: > > Assuming the following: > - Implicit upgrade to TLS mid-connection is not needed. And > - There is overall connection magic (to break HTTP/1.x). Yes. I assume the same. This magic is the first octets of a connection and cannot be used elsewhere safely. Once some other protocol has been started we must use that protocols defined Upgrade mechanism to change to HTTP/2 explicitly. > Then: > The TLS test occurs against that overall connection magic, > not against the beginning of the frame structure. > > And given that magic is thought to have the high bit of the > first byte set (the exact form needs more testing to determine), > telling it apart from TLS, which always starts with 0x16. > > > Now, to Websocket: I don't think websocket first byte values > are very constrained. Some extensions assign a meaning for > the RSV bits in the first byte or for other opcodes (or does > the latter require a new version of Websockets?). My understanding of WebSockets RFC is that the first frame mandates those bits as 0 and extensions are then negotiated which allow them to be used on following frames. By the time negotiation has indicated those bits a flag meaning we are already certain about the protocol. Under that assumption WebSockets vs TLS is also constrained in that the RSV1-RSV3 bits MUST be 0 in valid WebSockets, which RSV3 overlaps with the '1' hex digit in 0x16. > Additionally there is a FIN bit there too... Intentional. So that HTTP/2 can be defined as an extension to WebSockets and clients Upgrade: to it from inside WebSockets cleanly - broken WebSockets implementations mishandling the WS Upgrade frame will see the HTTP/2 initial handshake as a 0-length frame with FIN set. Amos
Received on Thursday, 7 February 2013 02:50:44 UTC