W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Framing and control-frame continuations

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 07 Feb 2013 15:50:12 +1300
Message-ID: <51131664.3010802@treenet.co.nz>
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.

Received on Thursday, 7 February 2013 02:50:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC