Code change:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Related discussion:
text: to indicate the end of the body. The header fields included in the HEADERS+PRIORITY frame contain all <del> of the HTTP header fields that are associated with an HTTP request. The header block in HTTP/2.0 is mostly unchanged from today's HTTP header block, with the following differences: The following fields that are carried in the request line in HTTP/1.1 (HTTP-p1) are defined as special-valued name-value pairs: the HTTP method for this request (e.g.  "GET", "POST", "HEAD", etc) (HTTP-p2) ":path" - the request-target for this URI with "/" prefixed (see HTTP-p1).  For example, for "http://www.google.com/ search?q=dogs" the path would be "/search?q=dogs". </del> <ins> of the HTTP header fields associated with an HTTP request.  The definitions of these headers are largely unchanged relative to HTTP/1.1, with a few notable exceptions: The HTTP/1.1 request-line has been split into two separate header fields named :method and :path, whose values specify the HTTP method for the request and the request-target, respectively.  The HTTP-version component of the request-line is removed entirely from the headers. The host and optional port portions of the request URI (see RFC3986, Section 3.2), is specified using the new :host header field. </ins> <del> These header fields MUST be present in HTTP requests. </del> <ins> A new :scheme header field has been added to specify the scheme portion of the request-target (e.g. "https") </ins> <del> In addition, the following two name-value pairs MUST be present in every request: </del> <ins> All header field names MUST be lowercased, and the definitions of all header fields names defined by HTTP/1.1 are updated to be all lowercase. </ins> <del> the host and optional port portions (see RFC3986) of the URI for this request (e.g. "www.google.com:1234").  This header field is the same as the HTTP 'Host' header field (HTTP-p1). </del> <ins> The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer- Encoding header fields are no longer valid and MUST not be sent. </ins> <del> the scheme portion of the URI for this request (e.g. "https") </del> <ins> All HTTP Requests MUST include the ":method", ":path", ":host", and ":scheme" header fields. </ins> <del> All header field names starting with ":" (whether defined in this document or future extensions to this document) MUST appear before any other header fields. </del> <ins> Header fields whose names begin with ":" (whether defined in this document or future extensions to this document) MUST appear before any other header fields. </ins> <del> Header field names MUST be all lowercase. The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer- Encoding header fields are not valid and MUST not be sent. </del> <ins> If a client sends a HEADERS+PRIORITY frame that omits a mandatory header, the server MUST reply with a HTTP 400 Bad Request reply. </ins> <del> User-agents MUST support gzip compression.  Regardless of the Accept-Encoding sent by the user-agent, the server may always send content encoded with gzip or deflate encoding. </del> <ins> User-agents MUST support gzip compression.  Regardless of the Accept- Encoding sent by the user-agent, the server may always send content encoded with gzip or deflate encoding. </ins> <del> If a server receives a request where the sum of the data frame payload lengths does not equal the size of the Content-Length header field, the server MUST return a 400 (Bad Request) error. </del> <ins> If a server receives a request where the sum of the data frame payload lengths does not equal the size of the Content-Length header field, the server MUST return a 400 (Bad Request) error. </ins> <del> Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the server of how much data to expect, which the server can used to track overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </del> <ins> Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the server of how much data to expect, which the server can used to track overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </ins> The user-agent is free to prioritize requests as it sees fit.  If the user-agent cannot make progress without receiving a resource, it should attempt to raise the priority of that resource.  Resources such as images, SHOULD generally use the lowest priority. <del> If a client sends a HEADERS+PRIORITY frame that omits a mandatory header, the server MUST reply with a HTTP 400 Bad Request reply. </del> If the server receives a data frame prior to a HEADERS or HEADERS+PRIORITY frame the server MUST treat this as a StreamErrorHandler of type PROTOCOL_ERROR.