Adjust multiple Content-Length handling

... to account for terminology changes, and to clarify that
it doesn't matter whether the values are on different lines.

Fixes #59.

draft-ietf-httpbis-messaging-latest.xml

@@ -1128,10 +1128,11 @@ https://www.example.org
   </t></li>
   <li><t>
    If a message is received without <x:ref>Transfer-Encoding</x:ref> and with
-   either multiple <x:ref>Content-Length</x:ref> header fields having
-   differing field values or a single Content-Length header field having an
-   invalid value, then the message framing is invalid and
-   the recipient &MUST; treat it as an unrecoverable error.
+   an invalid <x:ref>Content-Length</x:ref> header field, then the message
+   framing is invalid and the recipient &MUST; treat it as an unrecoverable
+   error, unless the field value can be successfully parsed as a
+   comma-separated list (<xref target="abnf.extension"/>), all values in the
+   list are valid, and all values in the list are the same.
    If this is a request message, the server &MUST; respond with
    a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    If this is a response message received by a proxy,
@@ -3494,6 +3495,7 @@ Upgrade: websocket
 
 <section title="Since draft-ietf-httpbis-messaging-07" anchor="changes.since.07">
 <ul x:when-empty="None yet.">
+   <li>In <xref target="message.body.length"/>, adjust requirements for handling multiple content-length values (<eref target="https://github.com/httpwg/http-core/issues/59"/>)</li>
 </ul>
 </section>
 </section>

draft-ietf-httpbis-semantics-latest.xml

@@ -3613,15 +3613,15 @@ bytes=500-700,601-999
    (<xref target="attack.protocol.element.length"/>).
 </t>
 <t>
-   If a message is received that has multiple Content-Length header fields
-   with field values consisting of the same decimal value, or a single
-   Content-Length header field with a field value containing a list of
-   identical decimal values (e.g., "Content-Length: 42, 42"), indicating that
-   duplicate Content-Length header fields have been generated or combined by an
-   upstream message processor, then the recipient &MUST; either reject the
-   message as invalid or replace the duplicated field values with a single
-   valid Content-Length field containing that decimal value prior to
-   determining the message body length or forwarding the message.
+   If a message is received that has a Content-Length header field value
+   consisting of the same decimal value as a comma-separated list (<xref
+   target="abnf.extension"/>) -- for example, "Content-Length: 42, 42" --
+   indicating that duplicate Content-Length header fields have been generated
+   or combined by an upstream message processor, then the recipient &MUST;
+   either reject the message as invalid or replace the duplicated field
+   values with a single valid Content-Length field containing that decimal
+   value prior to determining the message body length or forwarding the
+   message.
 </t>
 </section>
 
@@ -12337,6 +12337,7 @@ Content-Encoding: gzip
 
 <section title="Since draft-ietf-httpbis-semantics-07" anchor="changes.since.07">
 <ul x:when-empty="None yet.">
+   <li>In <xref target="header.content-length"/>, adjust requirements for handling multiple content-length values (<eref target="https://github.com/httpwg/http-core/issues/59"/>)</li>
 </ul>
 </section>
 </section>