Der HTTPRepr-DigestRequest-Header undResponse-Header bietet eineDigest der ausgewählten Repräsentation der Zielressource.Er kann verwendet werden, um die Integrität der gesamten ausgewählten Repräsentation zu validieren, sobald sie empfangen und rekonstruiert wurde.

Dieausgewählte Repräsentation ist das spezifische Format einer Ressource, das durchContent Negotiation ausgewählt wird.Details zur Repräsentation können ausRepräsentations-Headern wieContent-Language,Content-Type undContent-Encoding ermittelt werden.

Der Repräsentations-Digest bezieht sich auf die gesamte Repräsentation und nicht auf die Kodierung oder das Chunking der Nachrichten, die zum Senden verwendet werden.EinContent-Digest bezieht sich auf den Inhalt einer spezifischen Nachricht und hat unterschiedliche Werte, basierend auf derContent-Encoding undContent-Range jeder Nachricht.

Syntax

Repr-Digest: <digest-algorithm>=<digest-value>// Multiple digest algorithmsRepr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>

Direktiven

<digest-algorithm>

Der Algorithmus, der zum Erstellen eines Digests der Repräsentation verwendet wird.Nur zwei registrierte Digest-Algorithmen werden als sicher angesehen:sha-512 undsha-256.Die unsicheren (veralteten) registrierten Digest-Algorithmen sind:md5,sha (SHA-1),unixsum,unixcksum,adler (ADLER32) undcrc32c.

<digest-value>

Der Digest in Bytes der Repräsentation unter Verwendung des<digest-algorithm>.Die Wahl des Digest-Algorithmus bestimmt auch die zu verwendende Kodierung:sha-512 undsha-256 verwendenBase64-Kodierung, während einige veraltete Digest-Algorithmen wieunixsum eine Dezimalzahl verwenden.Im Gegensatz zu früheren Entwürfen der Spezifikation sind die standard-base64-kodierten Digest-Bytes in Doppelpunkten (:, ASCII 0x3A) als Teil derWörterbuch-Syntax eingeschlossen.

Die Verwendung unsicherer Digest-Algorithmen wird nicht empfohlen, da Kollisionen realistisch erzwungen werden können, was die Nützlichkeit des Digests schwächt.Außer bei der Arbeit mit veralteten Systemen (was unwahrscheinlich ist, da die meisten den veraltetenDigest-Header erwarten und diese Spezifikation nicht verstehen), sollten Sie erwägen, einenRepr-Digest auszulassen, anstatt einen mit einem unsicheren Digest-Algorithmus einzubeziehen.

Beschreibung

EinDigest-Header wurde in früheren Spezifikationen definiert, erwies sich jedoch als problematisch, da der Anwendungsbereich des Digests unklar war.Es war insbesondere schwierig zu unterscheiden, ob ein Digest auf die gesamte Ressourcen-Repräsentation oder auf den spezifischen Inhalt einer HTTP-Nachricht angewendet wurde.Daher wurden zwei separate Header spezifiziert (Content-Digest undRepr-Digest), um die Inhalte von HTTP-Nachrichten und die Digest von Ressourcenrepräsentationen zu vermitteln.

Beispiele

User-Agent, der einen Repr-Digest in Requests sendet

Im folgenden Beispiel sendet ein User-Agent einen Digest des Nachrichteninhalts unter Verwendung von SHA-512.Es werden sowohl einContent-Digest als auch einRepr-Digest gesendet, die sich aufgrund derContent-Encoding unterscheiden:

POST /bank_transfer HTTP/1.1Host: example.comContent-Encoding: zstdContent-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 denContent-Digest- oderRepr-Digest-Headern vergleichen, um die Integrität der Nachricht zu validieren.In Anfragen wie dem obigen Beispiel ist derRepr-Digest für den Server nützlicher, da er über die decodierte Repräsentation berechnet wird und in verschiedenen Szenarien konsistenter wäre.

HTTP-Antwort, bei derRepr-Digest undContent-Digest übereinstimmen

Ein HTTP-Server kann die gesamte Repräsentation unverändert in einer einzigen Nachricht senden.In diesem Fall habenRepr-Digest undContent-Digest gleiche Werte für die gleichen Digest-Algorithmen:

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:…Content-Type: text/yamlContent-Encoding: brContent-Length: 38054Content-Range: 0-38053/38054…[message body]

HTTP-Antworten, bei denenRepr-Digest undContent-Digest auseinanderfallen

Ein Server kann den Inhalt zum Senden komprimieren.In diesem Fall hängt derContent-Digest von derContent-Encoding ab und hat daher einen anderen Wert als derRepr-Digest-Header in einer Antwort:

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809…Content-Type: text/html; charset=utf-8Content-Encoding: br…[message body]

In einer weiteren Antwort verwendet der Server eine andere Komprimierungsmethode, was zu einem neuenContent-Digest, aber denselbenRepr-Digest-Digests führt:

…Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=:…Content-Type: text/html; charset=utf-8Content-Encoding: zstd…[message body]

Erfolgreiche HTTP-Anfrage-Antwort mitWant-Repr-Digest,Repr-Digest undContent-Digest

Die folgendePUT-Anfrage enthält einenWant-Repr-Digest-Header, der anzeigt, dass der Server einenRepr-Digest-Header mit einemsha-256-Digest einschließen sollte, wenn der Vorgang erfolgreich ist:

PUT /api/transact HTTP/1.1Want-Repr-Digest: sha-256=8Content-Type: text/json…[message body]

Der Server antwortet mit einer erfolgreichen201 Created-Antwort, dieRepr-Digest- undContent-Digest-Header mit sha-256-Digests der Repräsentation und des Inhalts enthält:

HTTP/1.1 201 CreatedRepr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:Content-Encoding: brContent-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:…[message body]

Fehlgeschlagene HTTP-Anfrage-Antwort mitRepr-Digest

In der folgenden Nachricht fordert ein User-Agent eine Ressource mit einem spezifischen sha-256-Digest an:

GET /api/last-transaction HTTP/1.1Accept: text/jsonRepr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:…

Ein406 Not Acceptable wird vom Server zurückgegeben, um anzuzeigen, dass die Operation aufgrund eines spezifischen Digests für die Ressource fehlgeschlagen ist.EinRepr-Digest-Header ist mit dem SHA-256-Digest-Wert enthalten, der zu einer erfolgreichen Antwort führen würde, wenn der User-Agent die Anfrage mit diesem Wert wiederholt:

HTTP/1.1 406 Not AcceptableRepr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:…

Spezifikationen

Browser-Kompatibilität

Dieser Header hat keine spezifikationsdefinierte Browser-Integration ("Browser-Kompatibilität" ist nicht anwendbar).Entwickler können HTTP-Header mitfetch() setzen und abrufen, um anwendungsspezifische Implementierungsverhalten bereitzustellen.

Siehe auch

• Content-Digest,Want-Content-Digest,Want-Repr-Digest
• ETag
• Content-Encoding
• Digitale Signaturen für APIs - Das SDK-Leitfaden verwendetContent-Digests für digitale Signaturen in HTTP-Anrufen (developer.ebay.com)