Content-Digest header
Der HTTP-Content-Digest-Anforderungs und Antwort-Header bietet einen Digest, der durch einen Hash-Algorithmus über den Nachrichtentext erstellt wird.
Ein Empfänger kann den Content-Digest verwenden, um den Inhalt der HTTP-Nachricht auf Integrität zu überprüfen.
Das Want-Content-Digest-Feld ermöglicht es einem Absender, einen Content-Digest zusammen mit seinen bevorzugten Hash-Algorithmen anzufordern.
Ein Content-Digest unterscheidet sich basierend auf Content-Encoding und Content-Range, jedoch nicht auf Transfer-Encoding.
In bestimmten Fällen kann ein Repr-Digest verwendet werden, um die Integrität von Teil- oder Mehrfachnachrichten im Vergleich zur vollständigen Darstellung zu gewährleisten.
Zum Beispiel bei Bereichsanfragen wird ein Repr-Digest immer den gleichen Wert haben, wenn nur die angeforderten Byte-Bereiche unterschiedlich sind, während sich der Content-Digest für jeden Teil unterscheidet.
Aus diesem Grund ist ein Content-Digest identisch mit einem Repr-Digest, wenn eine Darstellung in einer einzigen Nachricht gesendet wird.
| Header-Typ | Anforderungs-Header, Antwort-Header, Darstellungs-Header |
|---|---|
| Verbotener Anforderungs-Header | Nein |
Syntax
Content-Digest: <digest-algorithm>=<digest-value>
// Multiple digest algorithms
Content-Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>, …
Direktiven
<digest-algorithm>-
Der Algorithmus, der verwendet wird, um einen Digest des Nachrichtentextes zu erstellen. 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 in Bytes des Nachrichtentextes unter Verwendung des
<digest-algorithm>. Die Wahl des Digest-Algorithmus bestimmt auch die zu verwendende Kodierung:sha-512undsha-256verwenden base64-Kodierung, während einige veraltete Digest-Algorithmen wieunixsumeine dezimale Ganzzahl verwenden. Im Gegensatz zu früheren Entwürfen der Spezifikation werden die standardmäßig base64-kodierten Digest-Bytes aufgrund der Wörterbuch-Syntax in Doppelpunkte (:, ASCII 0x3A) eingeschlossen.
Beispiele
Benutzeragenten-Anfrage für einen SHA-256-Content-Digest
Im folgenden Beispiel fordert ein Benutzeragent einen Digest des Nachrichtentextes mit einer Präferenz für SHA-256 an, gefolgt von SHA-1 mit einer geringeren Präferenz:
GET /items/123 HTTP/1.1
Host: example.com
Want-Content-Digest: sha-256=10, sha=3
Der Server antwortet mit einem Content-Digest des Nachrichtentextes unter Verwendung des SHA-256-Algorithmus:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
{"hello": "world"}
Identische Content-Digest- und Repr-Digest-Werte
Ein Benutzeragent fordert eine Ressource ohne ein Want-Content-Digest-Feld an:
GET /items/123 HTTP/1.1
Host: example.com
Der Server ist so konfiguriert, dass er unaufgefordert Digest-Header in den Antworten sendet.
Die Repr-Digest- und Content-Digest-Felder haben übereinstimmende Werte, da sie denselben Algorithmus verwenden und in diesem Fall die gesamte Ressource in einer Nachricht gesendet wird:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 19
Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
{"hello": "world"}
Auseinandergehende Content-Digest- und Repr-Digest-Werte
Wenn dieselbe Anfrage wie im vorherigen Beispiel wiederholt wird, jedoch mit einer HEAD-Methode anstelle von GET, werden die Repr-Digest- und Content-Digest-Felder unterschiedlich sein:
GET /items/123 HTTP/1.1
Host: example.com
Der Repr-Digest-Wert wird derselbe wie zuvor sein, aber es gibt keinen Nachrichtentext, daher würde ein anderer Content-Digest vom Server gesendet werden:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Benutzeragent sendet einen Content-Digest in Anfragen
Im folgenden Beispiel sendet ein Benutzeragent einen Digest des Nachrichtentextes unter Verwendung von SHA-512.
Er sendet sowohl einen Content-Digest als auch einen Repr-Digest, die sich aufgrund der Content-Encoding unterscheiden:
POST /bank_transfer HTTP/1.1
Host: example.com
Content-Encoding: zstd
Content-Digest: sha-512=:ABC…=:
Repr-Digest: sha-512=:DEF…=:
{
"recipient": "Alex",
"amount": 900000000
}
Der Server kann einen Digest des empfangenen Inhalts berechnen und das Ergebnis mit den Content-Digest- oder Repr-Digest-Headern vergleichen, um die Integrität der Nachricht zu überprüfen.
In Anfragen wie dem obigen Beispiel ist der Repr-Digest für den Server nützlicher, da dieser über die dekodierte Darstellung berechnet wird und in verschiedenen Szenarien konsistenter wäre.
Spezifikationen
| Spezifikation |
|---|
| Digest Fields # section-2 |
Browser-Kompatibilität
Dieser Header hat keine spezifikationsdefinierte Browserintegration ("Browser-Kompatibilität" ist nicht anwendbar).
Entwickler können HTTP-Header mittels fetch() setzen und abrufen, um anwendungsspezifisches Implementierungsverhalten bereitzustellen.
Siehe auch
Want-Content-Digest-Header, um einen Content-Digest anzufordernRepr-Digest,Want-Repr-DigestDarstellungs-Digest-HeaderETag- Digitale Signaturen für APIs SDK-Leitfaden verwendet
Content-Digests für digitale Signaturen in HTTP-Aufrufen (developer.ebay.com)