Subject: non-tls http2 client has to send settings twice?

From: Dan Winship <[email-masked]>
Date: Tue, 10 Dec 2013 11:05:29 +0100

According to 3.2, a client connecting to an HTTP/2.0 server via plain 
http and Upgrade MUST send an HTTP2-Settings header field containing a 
SETTINGS frame. But then "Upon receiving the 101 response, the client 
sends a connection header (Section 3.5), which includes a SETTINGS frame."

So it has to send its settings twice? (Or else send a pointless empty 
SETTINGS frame the second time?)

3.2.1 says

    Providing these values in the Upgrade request ... gives a client
    an opportunity to provide other settings prior to receiving any
    frames from the server.

But is it really important that the client has the ability to provide 
settings prior to receiving any frames from the server, given that the 
server doesn't have the chance to do the same (and the server probably 
cares more about not having clients spam it than the client cares about 
not having the server spam it...)?

It seems like it would be simpler to just drop HTTP2-Settings, set 
default values for SETTINGS_INITIAL_WINDOW_SIZE and 
SETTINGS_MAX_CONCURRENT_STREAMS, and update the "clients are permitted 
to send additional frames ... without waiting to receive the server 
connection header" paragraph to also apply to the server's initial 
response in the http Upgrade case.

-- Dan

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 10:07:42 -0800

> SETTINGS frame the second time?)

Yep.  Pros and cons considered (at some length) this is what we came up with.

> server doesn't have the chance to do the same (and the server probably cares
> more about not having clients spam it than the client cares about not having
> the server spam it...)?

It's less a matter of importance, and more one of pragmatism.  Servers
already deal with this stuff.  And it's not an unbounded attack;
there's a default maximum on the receive window at both the TCP and
HTTP/2.0 connection layers.

We could protect the server further, sure.  Proposals have been made
<http://tools.ietf.org/html/draft-montenegro-httpbis-http2-server-profiles>,
<https://github.com/http2/http2-spec/issues/184>, but after some
fairly lengthy discussions, they aren't moving (though the issue isn't
closed either).