Appendix E. Migrating from RFC 3230

HTTP digests are computed by applying a hashing algorithm to input data. [RFC3230] defined the input data as an "instance", a term it also defined. The concept of an instance has since been superseded by the HTTP semantic term "representation". It is understood that some implementations of [RFC3230] mistook "instance" to mean HTTP content. Using content for the Digest field is an error that leads to interoperability problems between peers that implement [RFC3230].

[RFC3230] was only ever intended to use what HTTP now defines as selected representation data. The semantic concept of digest and representation are explained alongside the definition of the Repr-Digest field (Section 3).

While the syntax of Digest and Repr-Digest are different, the considerations and examples this document gives for Repr-Digest apply equally to Digest because they operate on the same input data; see Sections 3.1, 6 and 6.3.

[RFC3230] could never communicate the digest of HTTP message content in the Digest field; Content-Digest now provides that capability.

[RFC3230] allowed algorithms to define their output encoding format for use with the Digest field. This resulted in a mix of formats such as base64, hex, or decimal. By virtue of using Structured Fields, Content-Digest, and Repr-Digest use only a single encoding format. Further explanation and examples are provided in Appendix D.