1.1.Document Structure

This document is structured as follows:¶

• New request and response header and trailer field definitions.¶

  • Section 2 (Content-Digest),¶
  • Section 3 (Repr-Digest), and¶
  • Section 4 (Want-Content-Digest andWant-Repr-Digest).¶

• Considerations specific to representation data integrity.¶

  • Section 3.1 (State-changing requests),¶
  • Section 3.2 (Content-Location),¶
  • Appendix A contains worked examples of representation datain message exchanges, and¶
  • AppendixesB andC contain worked examplesofRepr-Digest andWant-Repr-Digest fields in message exchanges.¶
• Section 5 presents hash algorithm considerations and definesregistration procedures for future entries.¶

1.2.Concept Overview

The HTTP fields defined in this document can be used for HTTP integrity. Senderschoose a hashing algorithm and calculate a digest from an input related to theHTTP message. The algorithm identifier and digest are transmitted in an HTTPfield. Receivers can validate the digest for integrity purposes. Hashingalgorithms are registered in the "Hash Algorithms for HTTP Digest Fields" registry (seeSection 7.2).¶

Selecting the data on which digests are calculated depends on the use case of theHTTP messages. This document provides different fields for HTTP representationdata and HTTP content.¶

There are use cases where a simple digest of the HTTP content bytes isrequired. TheContent-Digest request and response header and trailer field isdefined to support digests of content (Section 6.4 of [HTTP]); seeSection 2.¶

For more advanced use cases, theRepr-Digest request and response headerand trailer field (Section 3) is defined. It contains a digest valuecomputed by applying a hashing algorithm to selected representation data(Section 8.1 of [HTTP]). BasingRepr-Digest on the selectedrepresentation makes it straightforward to apply it to use cases where themessage content requires some sort of manipulation to be considered asrepresentation of the resource or the content conveys a partial representation of a resource,such as range requests (seeSection 14 of [HTTP]).¶

Content-Digest andRepr-Digest support hashing algorithm agility.TheWant-Content-Digest andWant-Repr-Digest fields allowendpoints to express interest inContent-Digest andRepr-Digest, respectively, and to express algorithm preferences in either.¶

Content-Digest andRepr-Digest are collectively termed"Integrity fields".Want-Content-Digest andWant-Repr-Digest arecollectively termed "Integrity preference fields".¶

Integrity fields are tied to theContent-EncodingandContent-Type header fields. Therefore, a given resource may have multipledifferent digest values when transferred with HTTP.¶

Integrity fields apply to HTTP message content or HTTP representations. They donot apply to HTTP messages or fields. However, they can be combined with othermechanisms that protect metadata, such as digital signatures, in order toprotect the phases of an HTTP exchange in whole or in part. For example, HTTPMessage Signatures[SIGNATURES] could be used to sign Integrity fields, thusproviding coverage for HTTP content or representation data.¶

This specification does not define means for authentication, authorization, or privacy.¶

1.3.Obsoleting RFC 3230

[RFC3230] defined theDigest andWant-Digest HTTP fields for HTTP integrity.It also coined the terms "instance" and "instance manipulation" in order toexplain concepts, such as selected representation data (Section 8.1 of [HTTP]), that are now more universally defined and implemented as HTTPsemantics.¶

Experience has shown that implementations of[RFC3230] have interpreted themeaning of "instance" inconsistently, leading to interoperability issues. Themost common issue relates to the mistake of calculating the digest using (whatwe now call) message content, rather than using (what we now call)representation data as was originally intended. Interestingly, time has alsoshown that a digest of message content can be beneficial for some use cases, soit is difficult to detect if non-conformance to[RFC3230] is intentional orunintentional.¶

In order to address potential inconsistencies and ambiguity acrossimplementations ofDigest andWant-Digest, this document obsoletes[RFC3230]. The Integrity fields (Sections2 and3) and Integrity preference fields (Section 4)defined in this document are better aligned with current HTTP semantics andhave names that more clearly articulate the intended usages.¶

1.4.Notational Conventions

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[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the Augmented BNF defined in[RFC5234] and updated by[RFC7405]. This includes the rules CR (carriage return), LF (line feed), and CRLF (CR LF).¶

This document uses the following terminology fromSection 3 of [STRUCTURED-FIELDS] to specify syntax and parsing:Boolean, Byte Sequence, Dictionary, Integer, and List.¶

The definitions "representation", "selected representation", "representationdata", "representation metadata", "user agent", and "content" in this document are to beinterpreted as described in[HTTP].¶

This document uses the line folding strategiesdescribed in[FOLDING].¶

Hashing algorithm names respect the casing used in their definition document (e.g., SHA-1, CRC32c).¶

HTTP messages indicate hashing algorithms using an Algorithm Key (algorithms).Where the document refers to an Algorithm Key in prose, it is quoted (e.g., "sha", "crc32c").¶

The term "checksum" describes the output of applying an algorithm to a sequence of bytes, whereas "digest" is only used in relation to the value contained in the fields.¶

"Integrity fields" is the collective term forContent-Digest andRepr-Digest.¶

"Integrity preference fields" is the collective term forWant-Repr-DigestandWant-Content-Digest.¶

3.1.UsingRepr-Digest in State-Changing Requests

When the representation enclosed in a state-changing requestdoes not describe the target resource,the representation digestMUST be computed on therepresentation data.This is the only possible choice because representation digest requires completerepresentation metadata (seeSection 3).¶

In responses,¶

• if the representation describes the status of the request,Repr-DigestMUST be computed on the enclosed representation (seeAppendix B.8);¶
• if there is a referenced resource,Repr-DigestMUST be computed on the selected representation of the referenced resource even if that is different from the target resource. This might or might not result in computingRepr-Digest on the enclosed representation.¶

The latter case is done according to the HTTP semantics of the givenmethod, for example, using theContent-Location header field (seeSection 8.7 of [HTTP]).In contrast, theLocation header field does not affectRepr-Digest becauseit is not representation metadata.¶

For example, in PATCH requests, the representation digestwill be computed on the patch documentbecause the representation metadata refers to the patch document and notthe target resource (seeSection 2 of [PATCH]).In responses, instead, the representation digest will be computed on the selectedrepresentation of the patched resource.¶

3.2.Repr-Digest and Content-Location in Responses

When a state-changing method returns theContent-Location header field, theenclosed representation refers to the resource identified by its value andRepr-Digest is computed accordingly.An example is given inAppendix B.7.¶

6.1.HTTP Messages Are Not Protected in Full

This document specifies a data integrity mechanism that protects HTTPrepresentation data or content, but not HTTP header and trailer fields, fromcertain kinds of corruption.¶

Integrity fields are not intended to be a general protection against malicious tampering withHTTP messages.In the absence of additional security mechanisms, an on-path malicious actor can either remove a digest value entirely or substitute it with a new digest value computed over manipulated representation data or content.This attack can be mitigated by combining mechanisms described in thisdocument with other approaches suchas Transport Layer Security (TLS) or digital signatures (for example, HTTP MessageSignatures[SIGNATURES]).¶

6.2.End-to-End Integrity

Integrity fields can help detect representation data or content modification due to implementation errors,undesired "transforming proxies" (seeSection 7.7 of [HTTP]),or other actions as the data passes across multiple hops or system boundaries.Even a simple mechanism for end-to-end representation data integrity is valuablebecause a user agent can validate that resource retrieval succeeded before handing off to anHTML parser, video player, etc., for parsing.¶

Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages overmultiple hops since metadata could be manipulated at any stage. Methods to protectmetadata are discussed inSection 6.3.¶

6.3.Usage in Signatures

Digital signatures are widely used together with checksums to provide thecertain identification of the origin of a message[FIPS186-5]. Such signaturescan protect one or more HTTP fields and there are additional considerations whenIntegrity fields are included in this set.¶

There are no restrictions placed on the type or format of digital signature thatIntegrity fields can be used with. One possible approach is to combine them withHTTP Message Signatures[SIGNATURES].¶

Digests explicitlydepend on the "representation metadata" (e.g., the values ofContent-Type,Content-Encoding, etc.). A signature that protects Integrity fields but not other"representation metadata" can expose the communication to tampering. Forexample, an actor could manipulate theContent-Type field-value and cause adigest validation failure at the recipient, preventing the application fromaccessing the representation. Such an attack consumes the resources of bothendpoints. See alsoSection 3.2.¶

Signatures are likely to be deemed an adversarial setting when applyingIntegrity fields; seeSection 5.Repr-Digest offers an interestingpossibility when combined with signatures. In the scenario where there is nocontent to send, the digest of an empty string can be included in the messageand, if signed, can help the recipient detect if content was added either as a result of accident or purposeful manipulation. The opposite scenario is alsosupported; including an Integrity field for content and signing it can help arecipient detect where the content was removed.¶

Any mangling of Integrity fields might affect signature validation. Examples of such mangling include de-duplicating digests or combining different field values (seeSection 5.2 of [HTTP]).¶

6.4.Usage in Trailer Fields

Before sending Integrity fields in a trailer section, the sendershould consider that intermediaries are explicitly allowed to drop any trailer(seeSection 6.5.2 of [HTTP]).¶

When Integrity fields are used in a trailer section, the field-values are received after the content.Eager processing of content before the trailer section prevents digest validation, possibly leading toprocessing of invalid data.¶

One of the benefits of using Integrity fields in a trailer section is that itallows hashing of bytes as they are sent. However, it is possible todesign a hashing algorithm that requires processing of content in such a waythat would negate these benefits. For example, Merkle Integrity Content Encoding[MICE] requires content to be processed in reverse order.This means the complete data needs to be available, which means there isnegligible processing difference in sending an Integrity field in a header versusa trailer section.¶

6.5.Variations within Content-Encoding

Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generally not communicated as representation metadata. For instance, different compression levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm content coding defined in[RFC8188].¶

Since it is possible for there to be variation within content coding, the checksum conveyed by the Integrity fields cannot be used to provide a proof of integrity "at rest"unless the whole content is persisted.¶

6.6.Algorithm Agility

The security properties of hashing algorithms are not fixed.Algorithm agility (see[RFC7696]) is achieved by providing implementations with flexibilityto choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Fields registry; seeSection 7.2.¶

Transition from weak algorithms is supportedby negotiation of hashing algorithm usingWant-Content-Digest orWant-Repr-Digest (seeSection 4)or by sending multiple digests from which the receiver chooses.A receiver that depends on a digest for security will be vulnerableto attacks on the weakest algorithm it is willing to accept.Endpoints are advised that sending multiple values consumes resources that may be wasted if the receiver ignores them (seeSection 3).¶

While algorithm agility allows the migration to stronger algorithms,it does not prevent the use of weaker algorithms.Integrity fields do not provide any mitigations for downgrade or substitutionattacks (seeSection 1 of [RFC6211]) of the hashing algorithm.To protect against such attacks, endpoints could restrict their set of supported algorithmsto stronger ones and protect the fields' values by using TLS and/or digital signatures.¶

6.7.Resource Exhaustion

Integrity field validation consumes computational resources.In order to avoid resource exhaustion, implementations can restrictvalidation of the algorithm types, the number of validations, or the size of content.In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithmleaves the possibility of a downgrade attack (seeSection 6.6).¶

7.1.HTTP Field Name Registration

IANA has updated the"Hypertext Transfer Protocol (HTTP) Field Name Registry"[HTTP] as shown in the table below:¶

7.2.Creation of the Hash Algorithms for HTTP Digest Fields Registry

IANA has created the new "Hash Algorithms for HTTP Digest Fields"registry at<https://www.iana.org/assignments/http-digest-hash-alg/> andpopulated it with the entries inTable 2. The procedure fornew registrations is provided inSection 5.¶

7.3.Deprecate the Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry

IANA has deprecated the "Hypertext Transfer Protocol (HTTP) DigestAlgorithm Values" registry at<https://www.iana.org/assignments/http-dig-alg/> and replaced the note on that registry with the following text:¶

This registry is deprecated since it lists the algorithms that can be usedwith theDigest andWant-Digest fields defined in[RFC3230], which has been obsoleted byRFC 9530. While registration is not closed, new registrationsare encouraged to use theHash Algorithms for HTTP Digest Fields registry instead.¶

B.1.Server Returns Full Representation Data

In this example, the message content conveys complete representation data.This means that in the response,Content-Digest andRepr-Digestare both computed over the JSON object{"hello": "world"} followed by an LF; thus, they have the same value.¶

GET /items/123 HTTP/1.1Host: foo.example

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 19Content-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:Repr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:{"hello": "world"}

B.2.Server Returns No Representation Data

In this example, a HEAD request is used to retrieve the checksumof a resource.¶

The responseContent-Digest field-value is computed on empty content.Repr-Digest is calculated over the JSON object{"hello": "world"} followed by an LF, which is not shown because there is no content.¶

HEAD /items/123 HTTP/1.1Host: foo.example

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonContent-Digest: \  sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:Repr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

B.3.Server Returns Partial Representation Data

In this example, the client makes a range request and the server responds withpartial content.¶

GET /items/123 HTTP/1.1Host: foo.exampleRange: bytes=10-18

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 206 Partial ContentContent-Type: application/jsonContent-Range: bytes 10-18/19Content-Digest: \  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:Repr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:"world"}

In the response message above, note that theRepr-Digest andContent-Digests are different.TheRepr-Digest field-value is calculated across the entire JSON object{"hello": "world"} followed by an LF, and the field appears as follows:¶

NOTE: '\' line wrapping per RFC 8792Repr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

However, since the message content is constrained to bytes 10-18,theContent-Digest field-value is calculated over thesequence"world"} followed by an LF, thus resulting in the following:¶

NOTE: '\' line wrapping per RFC 8792Content-Digest: \  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:

B.4.Client and Server Provide Full Representation Data

The request contains aRepr-Digest field-value calculated on the enclosedrepresentation. It also includes anAccept-Encoding: br header field that advertises that theclient supports Brotli encoding.¶

The response includes aContent-Encoding: br that indicates the selectedrepresentation is Brotli-encoded. TheRepr-Digest field-value is thereforedifferent compared to the request.¶

For presentation purposes, the response body is displayed as a sequence ofhex-encoded bytes because it contains non-printable characters.¶

NOTE: '\' line wrapping per RFC 8792PUT /items/123 HTTP/1.1Host: foo.exampleContent-Type: application/jsonAccept-Encoding: brRepr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonContent-Location: /items/123Content-Encoding: brContent-Length: 23Repr-Digest: \  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:8B 08 80 7B 22 68 65 6C 6C 6F22 3A 20 22 77 6F 72 6C 64 227D 0A 03

B.5.Client Provides Full Representation Data and Server Provides No Representation Data

The requestRepr-Digest field-value is calculated on the enclosed content, whichis the JSON object{"hello": "world"} followed by an LF.¶

The responseRepr-Digest field-valuedepends on the representation metadata header fields, includingContent-Encoding: br, even when the response does not contain content.¶

NOTE: '\' line wrapping per RFC 8792PUT /items/123 HTTP/1.1Host: foo.exampleContent-Type: application/jsonContent-Length: 19Accept-Encoding: brRepr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:{"hello": "world"}

HTTP/1.1 204 No ContentContent-Type: application/jsonContent-Encoding: brRepr-Digest: sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:

B.6.Client and Server Provide Full Representation Data

The response contains two digest values using different algorithms.¶

For presentation purposes, the response body is displayed as a sequence ofhex-encoded bytes because it contains non-printable characters.¶

NOTE: '\' line wrapping per RFC 8792PUT /items/123 HTTP/1.1Host: foo.exampleContent-Type: application/jsonAccept-Encoding: brRepr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonContent-Encoding: brContent-Location: /items/123Repr-Digest: \  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\  sha-512=:db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY0sCpHAzZbj\  09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ==:8B 08 80 7B 22 68 65 6C 6C 6F22 3A 20 22 77 6F 72 6C 64 227D 0A 03

B.7.POST Response Does Not Reference the Request URI

The requestRepr-Digest field-value is computed on the enclosed representation(seeSection 3.1), which is the JSON object{"title": "NewTitle"} followed by an LF.¶

The representation enclosed in the response is a multiline JSON object followed by an LF.It refers to the resource identified byContent-Location (seeSection 6.4.2 of [HTTP]);thus, an application can useRepr-Digest in association with the resourcereferenced byContent-Location.¶

POST /books HTTP/1.1Host: foo.exampleContent-Type: application/jsonAccept: application/jsonAccept-Encoding: identityRepr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:{"title": "New Title"}

HTTP/1.1 201 CreatedContent-Type: application/jsonContent-Location: /books/123Location: /books/123Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:{  "id": "123",  "title": "New Title"}

B.8.POST Response Describes the Request Status

The requestRepr-Digest field-value is computed on the enclosed representation (seeSection 3.1), which is the JSON object{"title": "NewTitle"} followed by an LF.¶

The representation enclosed in the response describes the status of the request,soRepr-Digest is computed on that enclosed representation. It is a multilineJSON object followed by an LF.¶

ResponseRepr-Digest has no explicit relation with the resource referenced byLocation.¶

POST /books HTTP/1.1Host: foo.exampleContent-Type: application/jsonAccept: application/jsonAccept-Encoding: identityRepr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:{"title": "New Title"}

HTTP/1.1 201 CreatedContent-Type: application/jsonRepr-Digest: sha-256=:yXIGDTN5VrfoyisKlXgRKUHHMs35SNtyC3szSz1dbO8=:Location: /books/123{  "status": "created",  "id": "123",  "ts": 1569327729,  "instance": "/books/123"}

B.9.Digest with PATCH

This case is analogous to a POST request where the target resource reflects thetarget URI.¶

The PATCH request uses theapplication/merge-patch+json media type defined in[RFC7396].Repr-Digest is calculated on the content that corresponds to thepatch document and is the JSON object{"title": "New Title"} followed by anLF.¶

The responseRepr-Digest field-value is computed on the complete representation of the patchedresource. It is a multiline JSON object followed by an LF.¶

PATCH /books/123 HTTP/1.1Host: foo.exampleContent-Type: application/merge-patch+jsonAccept: application/jsonAccept-Encoding: identityRepr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:{"title": "New Title"}

HTTP/1.1 200 OKContent-Type: application/jsonRepr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:{  "id": "123",  "title": "New Title"}

Note that a204 No Content response without content, but with the sameRepr-Digest field-value, would have been legitimate too.In that case,Content-Digest would have been computed on an empty content.¶

B.10.Error Responses

In error responses, the representation data does not necessarily refer to thetarget resource. Instead, it refers to the representation of the error.¶

In the following example, a client sends the same request fromFigure 26 topatch the resource located at /books/123. However, the resource does not existand the server generates a 404 response with a body that describes the error inaccordance with[RFC9457].¶

The responseRepr-Digest field-value is computed on this enclosed representation.It is a multiline JSON object followed by an LF.¶

HTTP/1.1 404 Not FoundContent-Type: application/problem+jsonRepr-Digest: sha-256=:EXB0S2VF2H7ijkAVJkH1Sm0pBho0iDZcvVUHHXTTZSA=:{  "title": "Not Found",  "detail": "Cannot PATCH a non-existent resource",  "status": 404}

B.11.Use with Trailer Fields and Transfer Coding

An origin server sendsRepr-Digest as trailer field, so it can calculate digest-valuewhile streaming content and thus mitigate resource consumption.TheRepr-Digest field-value is the same as inAppendix B.1 becauseRepr-Digest is designed tobe independent of the use of one or more transfer codings (seeSection 3).¶

In the response content below, the string "\r\n" represents the CRLF bytes.¶

GET /items/123 HTTP/1.1Host: foo.example

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonTransfer-Encoding: chunkedTrailer: Repr-Digest8\r\n{"hello"\r\n8\r\n: "world\r\n3\r\n"}\n\r\n0\r\nRepr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n

C.1.Server Selects Client's Least Preferred Algorithm

The client requests a digest and prefers "sha". The server is free to reply with"sha-256" anyway.¶

GET /items/123 HTTP/1.1Host: foo.exampleWant-Repr-Digest: sha-256=3, sha=10

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonRepr-Digest: \  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:{"hello": "world"}

C.2.Server Selects Algorithm Unsupported by Client

The client requests a "sha" digest because that is the only algorithm itsupports. The server is not obliged to produce a response containing a "sha"digest; it instead uses a different algorithm.¶

GET /items/123 HTTP/1.1Host: foo.exampleWant-Repr-Digest: sha=10

NOTE: '\' line wrapping per RFC 8792HTTP/1.1 200 OKContent-Type: application/jsonRepr-Digest: \  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:{"hello": "world"}

C.3.Server Does Not Support Client Algorithm and Returns an Error

Appendix C.2 is an example where a server ignoresthe client's preferred digest algorithm.Alternatively, a server can also rejectthe request and return a response withan error status code such as 4xx or 5xx.This specification does not prescribeany requirement on status code selection;the following example illustrates one possibleoption.¶

In this example, the client requests a "sha"Repr-Digest, and the server returns anerror with problem details[RFC9457] contained in the content. The problemdetails contain a list of the hashing algorithms that the server supports. Thisis purely an example; this specification does not define any format orrequirements for such content.¶

GET /items/123 HTTP/1.1Host: foo.exampleWant-Repr-Digest: sha=10

HTTP/1.1 400 Bad RequestContent-Type: application/problem+json{  "title": "Bad Request",  "detail": "Supported hashing algorithms: sha-256, sha-512",  "status": 400}