- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Mon, 24 Feb 2014 08:55:47 +0000
- To: Kazu Yamamoto <kazu@iij.ad.jp>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24 February 2014 06:56, Kazu Yamamoto <kazu@iij.ad.jp> wrote: > I'm asking what kinds of setting parameters should/must be sent in > Direct and TLS. > > --Kazu The relevant text is in section 3.5 of the RFC. Quoting directly: > Upon establishment of a TCP connection and determination that > HTTP/2.0 will be used by both peers, each endpoint MUST send a > connection header as a final confirmation and to establish the > initial settings for the HTTP/2.0 connection. > > The client connection header starts with a sequence of 24 octets, > which in hex notation are: > > 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a > > (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence is > followed by a SETTINGS frame (Section 6.5). The client sends the > client connection header immediately upon receipt of a 101 Switching > Protocols response (indicating a successful upgrade), or as the first > application data octets of a TLS connection. If starting an HTTP/2.0 > connection with prior knowledge of server support for the protocol, > the client connection header is sent upon connection establishment. So assuming you're interested in client-side, you need to first send the client connection header and then send a SETTINGS frame. In the unlikely event that you don't want to change any setting from its default value you may send an 'empty' SETTINGS frame (i.e. a frame with no settings in it). Cory
Received on Monday, 24 February 2014 08:56:14 UTC