Original text:
HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of underlying transport protocols and the use of length or chunk- <del> delimited framing to detect completeness.  Additional integrity mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via extensible metadata fields.  Historically, the lack of a single integrity mechanism has been justified by the informal nature of most HTTP communication.  However, the prevalence of HTTP as an information access mechanism has resulted in its increasing use within environments where verification of message integrity is crucial. User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such that those means can be enabled within environments for which integrity is necessary.  For example, a browser being used to view medical history </del>  or drug interaction information needs to indicate to the user when such information is detected by the protocol to be incomplete, expired, or corrupted during transfer.  Such mechanisms might be selectively enabled via user agent extensions or the presence of <del> message integrity metadata in a response.  At a minimum, user agents ought to provide some indication that allows a user to distinguish between a complete and incomplete response message (incomplete.messages) when such verification is desired. </del>  11.4.

Reviewer comments:
I didn't want to make this too disruptive, so I concentrated on the high points. Related to the changes in . Breakdown: integrity is important (existing text) HTTPS provides integrity, but you have to be careful with truncation (includes existing example) HTTP provides no integrity extensions can be used to provide additional protection, including managing the risk of intermediaries messing around (massaging existing text)
talks about message integrity in general terms. The introductory sentence is good, but it then seemingly intermingles several different factors that might be relevant: Accidental corruption of messages in the network. This is not something that applies to HTTPS, but it is relevant for the cleartext variant. The use of intermediaries that might not be trusted not to modify messages. Noting here that this is likely selective as intermediaries need to modify certain parts of messages. Attacks on the protocol, which break down further: a. Attacks on cleartext HTTP, which has no real defense. b. Attacks on TLS, which has good defenses on the whole, though less so with respect to truncation of responses. This is due to the way that HTTP/1.1 allows connection termination (which is under attacker influence) to end a response and the way that TLS in practice is really poor at propagating close_notify in a way that is distinguishable from TCP closure. Overall, I think that this text could be made clearer.

Revised text:
HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of underlying transport protocols and the use of length or chunk-  <ins> delimited framing to detect completeness.  Historically, the lack of a single integrity mechanism has been justified by the informal nature of most HTTP communication.  However, the prevalence of HTTP as an information access mechanism has resulted in its increasing use within environments where verification of message integrity is crucial. The mechanisms provided with the "https" scheme, such as authenticated encryption, provide protection against modification of messages.  Care is needed however to ensure that connection closure cannot be used to truncate messages (see tls.connection.closure). User agents might refuse to accept incomplete messages or treat them specially.  For example, a browser being used to view medical history </ins> or drug interaction information needs to indicate to the user when such information is detected by the protocol to be incomplete, expired, or corrupted during transfer.  Such mechanisms might be selectively enabled via user agent extensions or the presence of  <ins> message integrity metadata in a response. The "http" scheme provides no protection against accidental or malicious modification of messages. Extensions to the protocol might be used to mitigate the risk of unwanted modification of messages by intermediaries, even when the "https" scheme is used.  Integrity might be assured by using hash functions or digital signatures that are selectively added to messages via extensible metadata fields. </ins> 11.4.