Repr-Digest header
Der HTTP-Repr-Digest-Anfrage- und Antwort-Header enthält einen Digest der ausgewählten Repräsentation der Zielressource.
Mit ihm lässt sich die Integrität der gesamten ausgewählten Repräsentation überprüfen, sobald sie empfangen und rekonstruiert wurde.
Die ausgewählte Repräsentation ist das spezifische Format einer Ressource, das durch Inhaltsaushandlung ausgewählt wurde.
Details zur Repräsentation lassen sich aus Repräsentations-Headern wie Content-Language, Content-Type und Content-Encoding ermitteln.
Der Repräsentations-Digest bezieht sich auf die gesamte Repräsentation und nicht auf die Kodierung oder Aufteilung der Nachrichten, mit denen sie übertragen wird.
Ein Content-Digest bezieht sich auf den Inhalt einer bestimmten Nachricht und hat je nach Content-Encoding und Content-Range der jeweiligen Nachricht unterschiedliche Werte.
| Header-Typ | Anfrage-Header, Antwort-Header, Repräsentations-Header |
|---|---|
| Verbotener Anfrage-Header | Nein |
Syntax
Repr-Digest: <digest-algorithm>=<digest-value>
// Multiple digest algorithms
Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>
Repr-Digest ist ein Wörterbuch strukturierter Felder (RFC 9651: Structured Field Values for HTTP), dessen Schlüssel <digest-algorithm> und dessen Werte <digest-value> sind.
Direktiven
<digest-algorithm>-
Der Algorithmus, mit dem ein Digest der Repräsentation erstellt wird. Nur zwei registrierte Digest-Algorithmen gelten als sicher:
sha-512undsha-256. Die unsicheren (veralteten) registrierten Digest-Algorithmen sind:md5,sha(SHA-1),unixsum,unixcksum,adler(ADLER32) undcrc32c. <digest-value>-
Der Digest der gesamten Daten der ausgewählten Repräsentation (siehe Abschnitt 8.1 der HTTP-Semantik-Spezifikation), berechnet mit
<digest-algorithm>, base64-kodiert und von Doppelpunkten (:, ASCII 0x3A) umschlossen. Diese Kodierung wird in der Spezifikation als Byte-Sequenz bezeichnet.
Beispiele
In allen Beispielen sind die Endpunkte so konfiguriert, dass sie Digest-Header ohne vorherige Anforderung senden. Der Absender könnte optional die Felder Want-Content-Digest und Want-Repr-Digest verwenden, um einen Content-Digest oder Repr-Digest zusammen mit den bevorzugten Hash-Algorithmen anzufordern.
Ein SHA-256-Repr-Digest in einer Antwort
Ein User-Agent fordert eine Ressource an:
GET /items/123 HTTP/1.1
Host: example.com
Der Server antwortet mit einem Repr-Digest der Repräsentation, der mit dem SHA-256-Algorithmus berechnet wurde.
Der Digest wird über die exakten Bytes der Repräsentation {"hello": "mdn"} berechnet (16 Bytes, ausdrücklich ohne einen abschließenden Zeilenumbruch):
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
{"hello": "mdn"}
Identische Content-Digest- und Repr-Digest-Werte
Ein User-Agent fordert eine Ressource an:
GET /items/123 HTTP/1.1
Host: example.com
Der Server antwortet mit einem Content-Digest und einem Repr-Digest für den Nachrichteninhalt, die mit dem SHA-256-Algorithmus berechnet wurden.
Die Felder Repr-Digest und Content-Digest haben denselben Wert, weil sie mit demselben Algorithmus über dieselben Bytes, {"hello": "mdn"} (16 Bytes), berechnet werden und in diesem Fall die gesamte Repräsentation in einer Nachricht gesendet wird:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Content-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
{"hello": "mdn"}
Unterschiedliche Content-Digest- und Repr-Digest-Werte
Ein User-Agent fordert mit einer Bereichsanfrage nur einen Teil einer Ressource an:
GET /items/123 HTTP/1.1
Host: example.com
Range: bytes=0-7
Der Server gibt eine 206 Partial Content-Antwort zurück, deren Nachrichteninhalt nur die angeforderten Bytes, {"hello" (8 Bytes), enthält.
Content-Digest deckt nur diese Bytes ab, während Repr-Digest weiterhin die gesamte Repräsentation {"hello": "mdn"} (16 Bytes) abdeckt. Daher unterscheiden sich die beiden Werte:
HTTP/1.1 206 Partial Content
Content-Type: application/json
Content-Range: bytes 0-7/16
Content-Digest: sha-256=:pKQv0IAKChzGfyfxu5TNqcnvxIzaG4XICf6NQnB1YhY=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Digest einer gzip-kodierten Repräsentation
In dieser Anfrage gibt der Client mit dem Accept-Encoding-Header an, dass er gzip-Komprimierung akzeptiert:
GET /items/123 HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Die Serverantwort enthält den Content-Encoding-Header. Dieser gibt an, dass die Nachrichten-Bytes aus der gzip-kodierten Repräsentation der Ressource stammen.
Der Digest wird über die gzip-kodierten Bytes statt über den ursprünglichen, nicht kodierten Text berechnet.
Hier wird der 16 Byte lange JSON-Body {"hello": "mdn"} mittels gzip zu einer 36 Byte langen Repräsentation komprimiert. Content-Digest und Repr-Digest werden über diese 36 Bytes berechnet (hier zur besseren Lesbarkeit hexadezimal dargestellt):
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 36
Content-Digest: sha-256=:6Gx6u1ZhhahDLs06Zc6ZEqXxUy8RNjy18CaMucjKOFk=:
Repr-Digest: sha-256=:6Gx6u1ZhhahDLs06Zc6ZEqXxUy8RNjy18CaMucjKOFk=:
1F 8B 08 00 00 00 00 00 02 FF AB 56 CA 48 CD C9 C9 57 B2 52 50 CA 4D C9 53 AA 05 00 35 D8 1D 91 10 00 00 00
Umgang mit Antworten ohne Inhalt bei Repr-Digest
Wenn dieselbe Ressource mit der Methode HEAD statt mit GET angefordert wird, hat die Antwort keinen Inhalt:
HEAD /items/123 HTTP/1.1
Host: example.com
Der Repr-Digest-Wert ist derselbe wie zuvor, da er sich immer auf die vollständige Repräsentation {"hello": "mdn"} bezieht.
Der Server sendet jedoch keinen Inhalt in der Antwort und kann den Content-Digest-Header weglassen:
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Statt Content-Digest bei fehlendem Inhalt wegzulassen, kann ein Server ihn ausdrücklich über eine leere Zeichenfolge berechnen.
Gemäß Abschnitt 6.3 von RFC 9530 kann ein Empfänger dadurch – insbesondere wenn der Digest durch eine HTTP-Nachrichtensignatur abgedeckt ist – überprüfen, dass kein Inhalt hinzugefügt oder entfernt wurde, statt lediglich festzustellen, dass der Header fehlt:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
Repr-Digest: sha-256=:bMGjiT1wkArOzyB9ReAdpW51FV4mHlQygPXGp+TtzG4=:
Senden von Digests in Anfragen durch einen User-Agent
Im folgenden Beispiel sendet ein User-Agent einen mit SHA-512 berechneten Digest des Nachrichteninhalts.
Der Digest wird über die exakten Bytes des Nachrichten-Bodys {"recipient":"Alex","amount":900000000} berechnet (39 Bytes, ausdrücklich ohne einen abschließenden Zeilenumbruch).
Da die gesamte Repräsentation in dieser einen Anfrage gesendet wird, haben Content-Digest und Repr-Digest denselben Wert:
POST /bank_transfer HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 39
Content-Digest: sha-512=:PlrIZYU3M76B30wGsL0h6O79BoxHTdAG+RnMPjOyECTSJCN/KnYdOrSCCWjxV3ckkyvdRmZ52//M3WbehCXcPw==:
Repr-Digest: sha-512=:PlrIZYU3M76B30wGsL0h6O79BoxHTdAG+RnMPjOyECTSJCN/KnYdOrSCCWjxV3ckkyvdRmZ52//M3WbehCXcPw==:
{"recipient":"Alex","amount":900000000}
Spezifikationen
| Spezifikation |
|---|
| Digest Fields |
Browser-Kompatibilität
Für diesen Header ist keine Browser-Integration durch eine Spezifikation definiert („Browser-Kompatibilität“ ist daher nicht anwendbar).
Entwickler können HTTP-Header mit fetch() setzen und auslesen, um anwendungsspezifisches Verhalten zu implementieren.
Siehe auch
Content-Digest,Want-Content-Digest,Want-Repr-DigestETagContent-Encoding- Der SDK-Leitfaden Digital Signatures for APIs beschreibt die Verwendung von
Content-Digest-Werten für digitale Signaturen in HTTP-Aufrufen (developer.ebay.com).