Ignore:
Timestamp:
Apr 8, 2011, 1:15:20 AM (9 years ago)
Author:
julian.reschke@…
Message:

Remove Content-MD5 (see #178)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.xml

    r1259 r1267  
    633633
    634634  <c>Content-Length</c> <c>&header-content-length;</c>
    635   <c>Content-MD5</c> <c><xref target="header.content-md5"/></c>
    636635  <c>Content-Range</c> <c>&header-content-range;</c>
    637636</texttable>
     
    14131412   interpreted relative to the effective request URI.
    14141413</t>
    1415 </section>
    1416 
    1417 <section title="Content-MD5" anchor="header.content-md5">
    1418   <iref primary="true" item="Content-MD5 header field" x:for-anchor=""/>
    1419   <iref primary="true" item="Header Fields" subitem="Content-MD5" x:for-anchor=""/>
    1420   <x:anchor-alias value="Content-MD5"/>
    1421 <t>
    1422    The "Content-MD5" header field, as defined in <xref target="RFC1864"/>, is
    1423    an MD5 digest of the payload body that provides an end-to-end message
    1424    integrity check (MIC) of the payload body (the message-body after any
    1425    transfer-coding is decoded). Note that a MIC is good for
    1426    detecting accidental modification of the payload body in transit, but is not
    1427    proof against malicious attacks.
    1428 </t>
    1429 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-MD5"/>
    1430   <x:ref>Content-MD5</x:ref> = &lt;base64 of 128 bit MD5 digest as per <xref target="RFC1864"/>&gt;
    1431 </artwork></figure>
    1432 <t>
    1433    The Content-MD5 header field &MAY; be generated by an origin server or
    1434    client to function as an integrity check of the payload body. Only
    1435    origin servers or user agents &MAY; generate the Content-MD5 header field;
    1436    proxies &MUST-NOT; generate it, as this would defeat its
    1437    value as an end-to-end integrity check. Any recipient &MAY; check that
    1438    the digest value in this header field matches a corresponding digest
    1439    calculated on payload body as received.
    1440 </t>
    1441 <t>
    1442    The MD5 digest is computed based on the content of the payload body,
    1443    including any content-coding, but not including any transfer-coding
    1444    applied to the message-body because such transfer-codings might be
    1445    applied or removed anywhere along the request/response chain.
    1446    If the message is received with a transfer-coding, that encoding &MUST;
    1447    be decoded prior to checking the Content-MD5 value against the received
    1448    payload.
    1449 </t>
    1450 <t>
    1451    HTTP extends RFC 1864 to permit the digest to be computed for MIME
    1452    composite media-types (e.g., multipart/* and message/rfc822), but
    1453    this does not change how the digest is computed as defined in the
    1454    preceding paragraph.
    1455 </t>
    1456 <t>
    1457    There are several consequences of this. The payload for composite
    1458    types &MAY; contain many body-parts, each with its own MIME and HTTP
    1459    header fields (including Content-MD5, Content-Transfer-Encoding, and
    1460    Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding
    1461    or Content-Encoding header field, it is assumed that the content
    1462    of the body-part has had the encoding applied, and the body-part is
    1463    included in the Content-MD5 digest as is &mdash; i.e., after the
    1464    application. The Transfer-Encoding header field is not allowed within
    1465    body-parts.
    1466 </t>
    1467 <t>
    1468    Conversion of all line breaks to CRLF &MUST-NOT; be done before
    1469    computing or checking the digest: the line break convention used in
    1470    the text actually transmitted &MUST; be left unaltered when computing
    1471    the digest.
    1472 </t>
    1473 <x:note>
    1474   <t>
    1475     <x:h>Note:</x:h> While the definition of Content-MD5 is exactly the same for
    1476     HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
    1477     in which the application of Content-MD5 to HTTP entity-bodies
    1478     differs from its application to MIME entity-bodies. One is that
    1479     HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
    1480     does use Transfer-Encoding and Content-Encoding. Another is that
    1481     HTTP more frequently uses binary content types than MIME, so it is
    1482     worth noting that, in such cases, the byte order used to compute
    1483     the digest is the transmission byte order defined for the type.
    1484     Lastly, HTTP allows transmission of text types with any of several
    1485     line break conventions and not just the canonical form using CRLF.
    1486   </t>
    1487 </x:note>
    14881414</section>
    14891415
     
    15691495      <xref target="header.content-location"/>
    15701496   </c>
    1571    <c>Content-MD5</c>
    1572    <c>http</c>
    1573    <c>standard</c>
    1574    <c>
    1575       <xref target="header.content-md5"/>
    1576    </c>
    15771497   <c>Content-Type</c>
    15781498   <c>http</c>
     
    19201840</reference>
    19211841
    1922 <reference anchor="RFC1864">
    1923   <front>
    1924     <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
    1925     <author initials="J." surname="Myers" fullname="John G. Myers">
    1926       <organization>Carnegie Mellon University</organization>
    1927       <address><email>jgm+@cmu.edu</email></address>
    1928     </author>
    1929     <author initials="M." surname="Rose" fullname="Marshall T. Rose">
    1930       <organization>Dover Beach Consulting, Inc.</organization>
    1931       <address><email>mrose@dbc.mtview.ca.us</email></address>
    1932     </author>
    1933     <date month="October" year="1995"/>
    1934   </front>
    1935   <seriesInfo name="RFC" value="1864"/>
    1936 </reference>
    1937 
    19381842<reference anchor="RFC1950">
    19391843  <front>
     
    23722276</reference>
    23732277
     2278<reference anchor="RFC6151">
     2279  <front>
     2280    <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
     2281    <author initials="S." surname="Turner" fullname="S. Turner"/>
     2282    <author initials="L." surname="Chen" fullname="L. Chen"/>
     2283    <date year="2011" month="March" />
     2284        </front>
     2285  <seriesInfo name="RFC" value="6151" />
     2286</reference>
     2287
    23742288<reference anchor='BCP97'>
    23752289  <front>
     
    25792493<t>
    25802494  Change ABNF productions for header fields to only define the field value.
     2495  (<xref target="header.fields"/>)
     2496</t>
     2497<t>
     2498        Remove definition of Content-MD5 header field because it was inconsistently
     2499        implemented with respect to partial responses, and also because of known
     2500        deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
    25812501  (<xref target="header.fields"/>)
    25822502</t>
     
    26232543 language-tag ] )
    26242544<x:ref>Content-Location</x:ref> = absolute-URI / partial-URI
    2625 <x:ref>Content-MD5</x:ref> = &lt;base64 of 128 bit MD5 digest as per [RFC1864]&gt;
    26262545<x:ref>Content-Type</x:ref> = media-type
    26272546
     
    26692588; Content-Language defined but not used
    26702589; Content-Location defined but not used
    2671 ; Content-MD5 defined but not used
    26722590; Content-Type defined but not used
    26732591; MIME-Version defined but not used
     
    30662984    </t>
    30672985    <t>
     2986      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/178"/>:
     2987      "Content-MD5 and partial responses"
     2988    </t>
     2989    <t>
    30682990      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
    30692991      "untangle ABNFs for header fields"
Note: See TracChangeset for help on using the changeset viewer.