Re: Framing and control-frame continuations

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).

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?).
Additionally there is a FIN bit there too...


-Ilari

Received on Thursday, 7 February 2013 02:24:26 UTC