Ticket #178: i178.diff

p3-payload.xml

@@ -632 +632 @@
   <ttcol>Defined in...</ttcol>
 
   <c>Content-Length</c> <c>&header-content-length;</c>
-  <c>Content-MD5</c> <c><xref target="header.content-md5"/></c>
   <c>Content-Range</c> <c>&header-content-range;</c>
 </texttable>
 </section>
@@ -1414 +1413 @@
 </t>
 </section>
 
-<section title="Content-MD5" anchor="header.content-md5">
-  <iref primary="true" item="Content-MD5 header field" x:for-anchor=""/>
-  <iref primary="true" item="Header Fields" subitem="Content-MD5" x:for-anchor=""/>
-  <x:anchor-alias value="Content-MD5"/>
-<t>
-   The "Content-MD5" header field, as defined in <xref target="RFC1864"/>, is
-   an MD5 digest of the payload body that provides an end-to-end message
-   integrity check (MIC) of the payload body (the message-body after any
-   transfer-coding is decoded). Note that a MIC is good for
-   detecting accidental modification of the payload body in transit, but is not
-   proof against malicious attacks.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-MD5"/>
-  <x:ref>Content-MD5</x:ref> = &lt;base64 of 128 bit MD5 digest as per <xref target="RFC1864"/>&gt;
-</artwork></figure>
-<t>
-   The Content-MD5 header field &MAY; be generated by an origin server or
-   client to function as an integrity check of the payload body. Only
-   origin servers or user agents &MAY; generate the Content-MD5 header field;
-   proxies &MUST-NOT; generate it, as this would defeat its
-   value as an end-to-end integrity check. Any recipient &MAY; check that
-   the digest value in this header field matches a corresponding digest
-   calculated on payload body as received.
-</t>
-<t>
-   The MD5 digest is computed based on the content of the payload body,
-   including any content-coding, but not including any transfer-coding
-   applied to the message-body because such transfer-codings might be
-   applied or removed anywhere along the request/response chain.
-   If the message is received with a transfer-coding, that encoding &MUST;
-   be decoded prior to checking the Content-MD5 value against the received
-   payload.
-</t>
-<t>
-   HTTP extends RFC 1864 to permit the digest to be computed for MIME
-   composite media-types (e.g., multipart/* and message/rfc822), but
-   this does not change how the digest is computed as defined in the
-   preceding paragraph.
-</t>
-<t>
-   There are several consequences of this. The payload for composite
-   types &MAY; contain many body-parts, each with its own MIME and HTTP
-   header fields (including Content-MD5, Content-Transfer-Encoding, and
-   Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding
-   or Content-Encoding header field, it is assumed that the content
-   of the body-part has had the encoding applied, and the body-part is
-   included in the Content-MD5 digest as is &mdash; i.e., after the
-   application. The Transfer-Encoding header field is not allowed within
-   body-parts.
-</t>
-<t>
-   Conversion of all line breaks to CRLF &MUST-NOT; be done before
-   computing or checking the digest: the line break convention used in
-   the text actually transmitted &MUST; be left unaltered when computing
-   the digest.
-</t>
-<x:note>
-  <t>
-    <x:h>Note:</x:h> While the definition of Content-MD5 is exactly the same for
-    HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
-    in which the application of Content-MD5 to HTTP entity-bodies
-    differs from its application to MIME entity-bodies. One is that
-    HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
-    does use Transfer-Encoding and Content-Encoding. Another is that
-    HTTP more frequently uses binary content types than MIME, so it is
-    worth noting that, in such cases, the byte order used to compute
-    the digest is the transmission byte order defined for the type.
-    Lastly, HTTP allows transmission of text types with any of several
-    line break conventions and not just the canonical form using CRLF.
-  </t>
-</x:note>
-</section>
-
 <section title="Content-Type" anchor="header.content-type">
   <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
   <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
@@ -1568 +1494 @@
    <c>
       <xref target="header.content-location"/>
    </c>
-   <c>Content-MD5</c>
-   <c>http</c>
-   <c>standard</c>
-   <c>
-      <xref target="header.content-md5"/>
-   </c>
    <c>Content-Type</c>
    <c>http</c>
    <c>standard</c>
@@ -1919 +1839 @@
   <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
-<reference anchor="RFC1864">
-  <front>
-    <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
-    <author initials="J." surname="Myers" fullname="John G. Myers">
-      <organization>Carnegie Mellon University</organization>
-      <address><email>jgm+@cmu.edu</email></address>
-    </author>
-    <author initials="M." surname="Rose" fullname="Marshall T. Rose">
-      <organization>Dover Beach Consulting, Inc.</organization>
-      <address><email>mrose@dbc.mtview.ca.us</email></address>
-    </author>
-    <date month="October" year="1995"/>
-  </front>
-  <seriesInfo name="RFC" value="1864"/>
-</reference>
-
 <reference anchor="RFC1950">
   <front>
     <title>ZLIB Compressed Data Format Specification version 3.3</title>
@@ -2371 +2275 @@
   <seriesInfo name="RFC" value="5322"/>
 </reference>
 
+<reference anchor="RFC6151">
+  <front>
+    <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
+    <author initials="S." surname="Turner" fullname="S. Turner"/>
+    <author initials="L." surname="Chen" fullname="L. Chen"/>
+    <date year="2011" month="March" />
+        </front>
+  <seriesInfo name="RFC" value="6151" />
+</reference>
+
 <reference anchor='BCP97'>
   <front>
     <title>Handling Normative References to Standards-Track Documents</title>
@@ -2581 +2495 @@
   (<xref target="header.fields"/>)
 </t>
 <t>
+        Remove definition of Content-MD5 header field because it was inconsistently
+        implemented with respect to partial responses, and also because of known
+        deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
+  (<xref target="header.fields"/>)
+</t>
+<t>
   Remove ISO-8859-1 special-casing in Accept-Charset.
   (<xref target="header.accept-charset"/>)
 </t>
@@ -2622 +2542 @@
 <x:ref>Content-Language</x:ref> = *( "," OWS ) language-tag *( OWS "," [ OWS
  language-tag ] )
 <x:ref>Content-Location</x:ref> = absolute-URI / partial-URI
-<x:ref>Content-MD5</x:ref> = &lt;base64 of 128 bit MD5 digest as per [RFC1864]&gt;
 <x:ref>Content-Type</x:ref> = media-type
 
 <x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT
@@ -2668 +2587 @@
 ; Content-Encoding defined but not used
 ; Content-Language defined but not used
 ; Content-Location defined but not used
-; Content-MD5 defined but not used
 ; Content-Type defined but not used
 ; MIME-Version defined but not used
 </artwork></figure></section>
@@ -3065 +2983 @@
       "Default charsets for text media types"
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/178"/>:
+      "Content-MD5 and partial responses"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
       "untangle ABNFs for header fields"
     </t>