Content-Digest header
Der HTTP Content-Digest Request- und Response-Header bieten einen Digest, der durch einen Hashing-Algorithmus auf den Nachrichtentext angewendet 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 Hashing-Algorithmen anzufordern. Ein Inhaltsdigest wird basierend auf Content-Encoding und Content-Range, aber nicht auf Transfer-Encoding unterschiedlich sein.
In bestimmten Fällen kann ein Repr-Digest verwendet werden, um die Integrität von Teil- oder Mehrteilnachrichten im Vergleich zur vollständigen Darstellung zu validieren. Beispielsweise hat bei Bereichsabfragen ein Repr-Digest immer denselben Wert, wenn sich nur die angeforderten Byte-Bereiche unterscheiden, während der Inhaltsdigest für jeden Teil unterschiedlich ist. Aus diesem Grund ist ein Content-Digest identisch mit einem Repr-Digest, wenn eine Darstellung in einer einzigen Nachricht gesendet wird.
| Headertyp | Request-Header, Response-Header, Representation-Header |
|---|---|
| Verbotener Request-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 sind die standardmäßig base64-kodierten Digest-Bytes von Doppelpunkten umschlossen (:, ASCII 0x3A) als Teil der Dictionary-Syntax.
Beschreibung
Ein Digest-Header wurde in früheren Spezifikationen definiert, erwies sich jedoch als problematisch, da der Umfang dessen, worauf sich der Digest bezieht, nicht klar war. Insbesondere war es schwierig zu unterscheiden, ob ein Digest auf die gesamte Ressourcenrepräsentation oder auf den spezifischen Inhalt einer HTTP-Nachricht angewendet wurde. Daher wurden zwei separate Header spezifiziert (Content-Digest und Repr-Digest), um HTTP-Nachrichteninhalts-Digests bzw. Ressourcenrepräsentations-Digests zu übermitteln.
Beispiele
Benutzeragent-Anfrage für einen SHA-256 Content-Digest
Im folgenden Beispiel fordert ein Benutzeragent einen Digest des Nachrichtentextes mit der Präferenz für SHA-256 an, gefolgt von SHA-1 mit geringerer 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 unaufgeforderte Digest-Header in 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"}
Abweichende Content-Digest- und Repr-Digest-Werte
Wenn dieselbe Anfrage wie im vorherigen Beispiel wiederholt wird, jedoch eine HEAD-Methode anstelle einer GET verwendet wird, werden die Repr-Digest- und Content-Digest-Felder unterschiedlich sein:
GET /items/123 HTTP/1.1
Host: example.com
Der Repr-Digest-Wert bleibt derselbe wie zuvor, aber es gibt keinen Nachrichtentext, sodass ein anderer Content-Digest vom Server gesendet wird:
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 mit SHA-512. Er sendet sowohl einen Content-Digest als auch einen Repr-Digest, die sich aufgrund des Content-Encoding voneinander 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 erhaltenen Inhalts berechnen und das Ergebnis mit den Content-Digest- oder Repr-Digest-Headern vergleichen, um die Nachrichtenintegration zu validieren. Bei 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 unterschiedlichen Szenarien konsistenter wäre.
Spezifikationen
| Spezifikation |
|---|
| Digest Fields # section-2 |
Browser-Kompatibilität
Dieser Header hat keine spezifikationsdefinierte Browser-Integration ("Browser-Kompatibilität" ist nicht anwendbar). Entwickler können HTTP-Header über fetch() setzen und abrufen, um anwendungsspezifisches Implementierungsverhalten bereitzustellen.
Siehe auch
Want-Content-Digest-Header, um einen Inhaltsdigest anzufordernRepr-Digest,Want-Repr-DigestRepräsentationsdigest-HeaderETag- Digitale Signaturen für APIs SDK-Leitfaden verwendet
Content-Digests für digitale Signaturen in HTTP-Aufrufen (developer.ebay.com)