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 pdf html 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.
Show full document text