A request fingerprint is a derived representation of an API request used to compare requests or bind a request to a digital signature. Its contents depend on the job: deduplication can hash the request body, while authentication must include every request component that affects meaning or integrity. section 26.3.4 section 30.3.4
Choose the fingerprint contents according to the failure it must prevent:
- For request deduplication, store a body fingerprint alongside the request identifier and cached response; matching fingerprints permit replay, while mismatches should produce a 409 Conflict. section 26.3.4
- For HTTP authentication, include the method, path, host, and body content; include the request time when freshness matters. section 30.3.4
- Represent large bodies through a Base64-encoded SHA-256 digest, then assemble the selected fields in a stable, ordered form. section 30.3.4
Chat-room update with a colliding request ID
An update carries requestId and a body-derived SHA-256 hash. The service caches both after the first update. A later request with the same identifier returns the cached response only when its hash matches; otherwise it rejects the request as a conflict instead of returning an unrelated result. section 26.3.4
Signed HTTP request
A fingerprint can contain `(request-target): patch /chatRooms/1`, the destination host, a Date header, and a SHA-256 Digest value. Verification recomputes the body digest and fingerprint before checking the signature with the selected public key. section 30.3.6
Table 30.1 Components necessary for fingerprinting a HTTP request (view table figure)
Use the component table to inspect which HTTP locations contribute to a fingerprint and what each field represents. section 30.3.4
