]> HTTP Problem Types for Digest Fields Transloadit
marius@transloadit.com
Cloudflare
lucas@lucaspardue.com
Par-Tec
Italy robipolli@gmail.com
Web and Internet Transport Building Blocks for HTTP APIs next generation unicorn sparkling distributed ledger This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Building Blocks for HTTP APIs Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction defines HTTP fields for exchanging integrity digests and preferences, but does not specify, require or recommend any specific behavior for error handling relating to integrity by design. The responsibility is instead delegated to applications. This draft defines a set of problem types () that can be used by server applications to indicate that a problem was encountered while dealing with a request carrying integrity fields and integrity preference fields. For example, a request message may include content alongside Content-Digest and Repr-Digest fields that use a digest algorithm the server does not support. An application could decide to reject this request because it cannot validate the integrity. Using a problem type, the server can provide machine-readable error details to aid debugging or error reporting, as shown in the following example.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Some examples in this document contain long lines that may be folded, as described in . The terms "integrity fields" and "integrity preference fields" in this document are to be interpreted as described in . The term "problem type" in this document is to be interpreted as described in . The terms "request", "response", "intermediary", "sender", and "server" are from .
Problem Types The following section defines three problem types to express common problems that occur when handling integrity or integrity preference fields on the server. These problem types use the digest- prefix in their type URI. Other problem types that are defined outside this document, yet specific to digest related problems, may reuse this prefix.
Unsupported Hashing Algorithm This section defines the "https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm" problem type. A server MAY use this problem type if it wants to communicate to the client that one of the hashing algorithms referenced in the integrity or integrity preference fields present in the request is not supported. Two problem type extension members are defined, which SHOULD be populated for all responses using this problem type:
  • The unsupported-algorithm extension member identifies the unsupported algorithm from the request. Its value is the corresponding algorithm key.
  • The header extension member as defined in .
The response can include the corresponding integrity preference field to indicate the server's algorithm support and preference. This problem type is a hint to the client about algorithm support, which the client could use to retry the request with a different, supported, algorithm. Example:
A request with a sha-256 integrity field, which is not supported by the server
Response indicating the problem and advertising the supported algorithms
This problem type can also be used when a request contains an integrity preference field with an unsupported algorithm. For example:
A request with a sha-256 integrity preference field, which is not supported by the server
Response indicating the problem and advertising the supported algorithms
Invalid Digest Value This section defines the "https://iana.org/assignments/http-problem-types#digest-invalid-value" problem type. A server MAY use this problem type when responding to a request, whose integrity fields include a digest value, that cannot be generated by the corresponding hashing algorithm. For example, if the digest value of the sha-512 hashing algorithm is not 64 bytes long, it cannot be a valid SHA-512 digest value and the server can skip computing the digest value. This problem type MUST NOT be used if the server is not able to parse the integrity fields according to , for example because of a syntax error in the field value. One problem type extension member is defined, which SHOULD be populated for all responses using this problem type:
  • The header extension member as defined in .
The server SHOULD include a human-readable description why the value is considered invalid in the title member. This problem type indicates a fault in the sender's calculation or encoding of the digest value. A retry of the same request without modification will likely not yield a successful response. The following example shows a request with the content {"hello": "world"} (plus LF), but the digest has been truncated. The subsequent response indicates the invalid SHA-512 digest.
A request with a sha-512 integrity field, whose digest has been truncated to 32 bytes
Response indicating that the provided digest is too short
Mismatching Digest Value This section defines the "https://iana.org/assignments/http-problem-types#digest-mismatching-value" problem type. A server MAY use this problem type when responding to a request, whose integrity fields include a digest value that does not match the digest value that the server calculated for the request content or representation. Three problem type extension members are defined, which SHOULD be populated for all responses using this problem type:
  • The algorithm extension member is the algorithm key of the used hashing algorithm.
  • The provided-digest extension member is the digest value taken from the request's integrity fields. The digest value is serialized as a byte sequence as described in .
  • The header extension member as defined in .
The problem type intentionally does not include the digest value calculated by the server to avoid attackers abusing this information for oracle attacks. If the sender receives this problem type, the request might be modified unintentionally by an intermediary. The sender could use this information to retry the request without modification to address temporary transmission issues. The following example shows a request with the content {"hello": "woXYZ"} (plus LF), but the representation digest for {"hello": "world"} (plus LF). The subsequent response indicates the mismatching SHA-256 digest values.
A request with a sha-256 integrity field, which does not belong to the representation
Response indicating the mismatching digests
Identifying Problem Causing Headers Requests can include multiple integrity or integrity preference fields. For example, they may use the Content-Digest and Repr-Digest fields simultaneously or express preferences for content and representation digests at the same time. To aid troubleshooting, it's useful to identify the header field, whose value caused the problem detailed in the response. For this reason, the header extension member is defined, which SHOULD be populated for all responses using the problem types defined in this document. The header extension member's value is the header field name that caused the problem. Since HTTP header field names are case-insensitive and not all HTTP versions preserve their casing, the casing of extension member's value might not match the request header field name's casing.
Security Considerations Disclosing error details could leak information such as the presence of intermediaries or the server's implementation details. Moreover, they can be used to fingerprint the server. To mitigate these risks, a server could assess the risk of disclosing error details and prefer a general problem type over a more specific one. When a server informs the client about mismatching digest values, it should not expose the calculated digest to avoid exposing information that can be abused for oracle attacks.
IANA Considerations IANA is asked to register the following entries in the "HTTP Problem Types" registry at https://www.iana.org/assignments/http-problem-types.
Registration of "digest-unsupported-algorithm" Problem Type
Type URI:
https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm
Title:
Unsupported Hashing Algorithm
Recommended HTTP status code:
400
Reference:
of this document
Registration of "digest-invalid-value" Problem Type
Type URI:
https://iana.org/assignments/http-problem-types#digest-invalid-value
Title:
Invalid Digest Value
Recommended HTTP status code:
400
Reference:
of this document
Registration of "digest-mismatching-value" Problem Type
Type URI:
https://iana.org/assignments/http-problem-types#digest-mismatching-value
Title:
Mismatching Digest Value
Recommended HTTP status code:
400
Reference:
of this document
Normative References Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Problem Details for HTTP APIs This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Structured Field Values for HTTP This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.