RFC 3230 (rfc3230) - Page 2 of 13

Instance Digests in HTTP

Alternative Format: Original Text Document


RFC 3230                Instance Digests in HTTP            January 2002


   6 IANA Considerations............................................. 10
   7 Security Considerations......................................... 10
   8 Acknowledgements................................................ 10
   9 References...................................................... 10
   10 Authors' Addresses............................................. 12
   11 Full Copyright Statement....................................... 13

1 Introduction

   Although HTTP is typically layered over a reliable transport
   protocol, such as TCP, this does not guarantee reliable transport of
   information from sender to receiver.  Various problems, including
   undetected transmission errors, programming errors, corruption of
   stored data, and malicious intervention can cause errors in the
   transmitted information.

   A common approach to the problem of data integrity in a network
   protocol or distributed system, such as HTTP, is the use of digests,
   checksums, or hash values.  The sender computes a digest and sends it
   with the data; the recipient computes a digest of the received data,
   and then verifies the integrity of this data by comparing the
   digests.

   Checksums are used at virtually all layers of the IP stack.  However,
   different digest algorithms might be used at each layer, for reasons
   of computational cost, because the size and nature of the data being
   protected varies, and because the possible threats to data integrity
   vary.  For example, Ethernet uses a Cyclic Redundancy Check (CRC).
   The IPv4 protocol uses a ones-complement checksum over the IP header
   (but not the rest of the packet).  TCP uses a ones-complement
   checksum over the TCP header and data, and includes a "pseudo-header"
   to detect certain kinds of programming errors.

   HTTP/1.1 [4] includes a mechanism for ensuring message integrity, the
   Content-MD5 header.  This header is actually defined for MIME-
   conformant messages in a standalone specification [10].  According to
   the HTTP/1.1 specification,

      The Content-MD5 entity-header field [...]  is an MD5 digest of the
      entity-body for the purpose of providing an end-to-end message
      integrity check (MIC) of the entity-body.

   HTTP/1.1 borrowed Content-MD5 from the MIME world based on an analogy
   between MIME messages (e.g., electronic mail messages) and HTTP
   messages (requests to or responses from an HTTP server).






Mogul, et. al.              Standards Track

Web Standards & Support: