Client advertising settings during Upgrade dance

[OsamaM]

This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request).

Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYN_STREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYN_REPLY.

The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc.

If we include the settings as part of the initial Upgrade GET then

1. Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler.
2. Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.

[mnot]

Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.

[OsamaM]

Addressed via "HTTP2-Settings Header Field" section.