Re: The first settings

I also had the same questions about first SETTINGS frame.
Is it possible to be noted in the specifications?

Best regards,
Moto Ishizawa


2014-02-24 17:55 GMT+09:00 Cory Benfield <cory@lukasa.co.uk>:

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