Original text:
(HTTP-p1).  The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.  For example: Requests that contain a request entity body MUST be sent in their <del> entirely before the client can send HTTP/2.0 frames.  This means that </del>  a large request entity can block the use of the connection until it is completely sent.

Reviewer comments:
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
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 SYNSTREAM 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 SYNREPLY. 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.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.

Revised text:
(HTTP-p1).  The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0. <ins> Additional to the Upgrade request, anticipating that the server will likely respond with some HTTP/2.0 frames, the client MUST send the payload of its SETTINGS frame within the HTTP/1.1 header.  In particular, if the server does not know the client's initial preferences (as expressed in a SETTINGS frame), it could send too much data in its response, or reserve multiple streams via PUSH_PROMISE despite the client's preference to the contrary.  To avoid this situation, these SETTINGS MUST be communicated by the client to the server in advance of the first HTTP/2.0 message from the server: SETTINGS_MAX_CONCURRENT_STREAMS, SETTINGS_INITIAL_WINDOW_SIZE (SettingFormat). NOTE: There may be additional SETTINGS added later on, e.g., due to header compression (TBD). The SETTINGS are conveyed in the following hop-by-hop HTTP/1.1 header: HTTP2-Settings = "HTTP2-Settings" ":" token68 token68 is defined in HTTP-p7.  The value of HTTP2-Settings is set to the base64url encoding of the payload of the SETTINGS frame as defined in SettingFormat.  Other than the fact that these SETTINGS are communicated by the client via an HTTP/1.1 header, they are otherwise indistinguishable from SETTINGS and their handling as detailed in SettingFormat. </ins> For example: Requests that contain a request entity body MUST be sent in their  <ins> entirety before the client can send HTTP/2.0 frames.  This means that </ins> a large request entity can block the use of the connection until it is completely sent.