Instance Digests in HTTP
RFC 3230
Document | Type |
RFC - Proposed Standard
(January 2002; No errata)
Was draft-mogul-http-digest (individual)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3230 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group J. Mogul Request for Comments: 3230 Compaq WRL Category: Standards Track A. Van Hoff Marimba January 2002 Instance Digests in HTTP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content- Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. Table of Contents 1 Introduction.................................................... 2 1.1 Other limitations of HTTP/1.1............................ 3 2 Goals........................................................... 4 3 Terminology..................................................... 5 4 Specification................................................... 6 4.1 Protocol parameter specifications........................ 6 4.1.1 Digest algorithms................................. 6 4.2 Instance digests......................................... 7 4.3 Header specifications.................................... 8 4.3.1 Want-Digest....................................... 8 4.3.2 Digest............................................ 9 5 Negotiation of Content-MD5...................................... 9 Mogul, et. al. Standards Track [Page 1] 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).Show full document text