Subject: The first settings

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 24 Feb 2014 11:40:53 +0900 (JST)

Hi,

draft-ietf-httpbis-http2-10 says that SETTINGS_MAX_CONCURRENT_STREAMS
and SETTINGS_INITIAL_WINDOW_SIZE are MUST for Upgrade.

However, I cannot find such a requirement for Direct and TLS. What
kinds of setting parameters should/must be sent in these two cases?

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Feb 2014 22:19:15 -0800

> and SETTINGS_INITIAL_WINDOW_SIZE are MUST for Upgrade.

They are MUST for HTTP2-Settings, which only appears in Upgrade.  This
is to address an imbalance in Upgrade where the server potentially
sends data first.  Having client settings available means that the
server is always the one that has to deal with unknown client
settings, regardless of how the protocol starts.

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 24 Feb 2014 15:56:23 +0900 (JST)

Hi Martin,

Thank you for your reply.

> settings, regardless of how the protocol starts.

I'm not asking about Upgrade.

I'm asking what kinds of setting parameters should/must be sent in
Direct and TLS.

--Kazu

---

From: Cory Benfield <[email-masked]>
Date: Mon, 24 Feb 2014 08:55:47 +0000

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

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 24 Feb 2014 19:57:49 +0900 (JST)

Hi Cory,

> default value you may send an 'empty' SETTINGS frame (i.e. a frame

An empty settings frame - that is what I want to know.
Thanks.

--Kazu

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 27 Feb 2014 14:14:33 +0900 (JST)

Hi

> An empty settings frame - that is what I want to know.

Let me ask one more question.

Why SETTINGS_MAX_CONCURRENT_STREAMS and SETTINGS_INITIAL_WINDOW_SIZE
are MUST for Upgrade but optional for Direct and TLS?

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Feb 2014 10:25:59 -0800

> are MUST for Upgrade but optional for Direct and TLS?

There's an asymmetry between Upgrade and the other modes.  In Upgrade,
the server gets the first opportunity to send it's SETTINGS.  That
means that clients are potentially exposed to the default values of
these values, but only if they Upgrade.

(Honestly, I don't think that this is a big issue - the server can't
really *do* anything until the client sends a request, but this is
what we have.)

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 28 Feb 2014 06:28:00 +0900

> these values, but only if they Upgrade.

It seems you're again explaining just the reason why we have the
HTTP2-Settings field in the Upgrade request. Sorry if it's just my bad.

Even when to start HTTP2 w/ prior knowledge, if the SETTINGS following the
client preface doesn't contain those parameters like an empty SETTINGS
frame as Cory mentioned, the clients are exposed to the default values. I
think Kazu is wondering why those two parameters are not also mandated for
such a preface SETTINGS frame exchanged in non-Upgrade modes.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Feb 2014 13:48:44 -0800

On 27 February 2014 13:28, Takeshi Yoshino <[email-masked]> wrote:
> if the SETTINGS following the client preface doesn't contain those
> parameters like an empty SETTINGS frame as Cory mentioned, the clients are
> exposed to the default values

Ahh, this is the question.  Well, that's just an inconsistency.

I think that it's perfectly OK to leave yourself exposed in this way.
Others disagree.  No effort has been made to fix it.  Someone once
suggested that we require all settings values always, for this reason.

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 28 Feb 2014 10:36:17 +0900 (JST)

Hi,

> suggested that we require all settings values always, for this reason.

If possible, please make it consistent and clarify it in the spec.

--Kazu

---

From: Cory Benfield <[email-masked]>
Date: Fri, 28 Feb 2014 08:51:20 +0000

> If possible, please make it consistent and clarify it in the spec.

I'd like some consistency here too. I don't really mind how we achieve
that consistency, though on balance it'd probably be easiest to say
that the client SHOULD send all settings, even if they're set to their
defaults.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Feb 2014 12:43:12 -0800

> that the client SHOULD send all settings, even if they're set to their

I think that we need to distinguish between the first time around,
where all settings is a good idea, and subsequent updates.

In any case:
https://github.com/http2/http2-spec/issues/419