Original text:
2.2. <del> HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol.  This specification defines version "1.1". protocol.version specifies the semantics of HTTP version numbers. The version of an HTTP/1.x message is indicated by an HTTP-version field in the . HTTP-version is case-sensitive. When an HTTP/1.1 message is sent to an HTTP/1.0 recipient RFC1945 or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 message if all of the newer features are ignored.  This specification places recipient-version requirements on some new features so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt of a message, that the recipient supports HTTP/1.1. Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages.  In other words, they are not allowed to blindly forward the without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages.  Forwarding an HTTP message without rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version to determine what features are safe to use for later communication with that sender. A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it is known or suspected that the client incorrectly implements the HTTP specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor version of the protocol.  Such protocol downgrades SHOULD NOT be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., ) uniquely match the values sent by a client known to be in error. 2.3. </del> The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a hash table by field name until the empty line, and then use the parsed data to

Reviewer comments:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.

Revised text:
2.2.  The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a hash table by field name until the empty line, and then use the parsed data to