Repr-Digest header
Der HTTP-Repr-Digest-Anfrage und Antwort-Header liefert einen Digest der ausgewählten Repräsentation der Zielressource.
Er kann verwendet werden, um die Integrität der gesamten ausgewählten Repräsentation zu validieren, nachdem sie empfangen und rekonstruiert wurde.
Die ausgewählte Repräsentation ist das spezifische Format einer Ressource, das durch Inhaltsverhandlung gewählt wird.
Details über die Repräsentation können aus Repräsentations-Headern bestimmt werden, wie z.B. Content-Language, Content-Type und Content-Encoding.
Der Repräsentations-Digest bezieht sich auf die gesamte Repräsentation, anstatt auf die Kodierung oder Teilung der Nachrichten, die verwendet werden, um sie zu senden.
Ein Content-Digest bezieht sich auf den Inhalt einer bestimmten Nachricht und hat unterschiedliche Werte, basierend auf der Content-Encoding und Content-Range jeder Nachricht.
| Header-Typ | 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>
Direktiven
<digest-algorithm>-
Der Algorithmus, der verwendet wird, um einen Digest der Repräsentation 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 der Repräsentation 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 standard-base64-kodierten Digest-Bytes als Teil der Dictionary-Syntax in Doppelpunkte (:, ASCII 0x3A) eingeschlossen.
Die Verwendung unsicherer Digest-Algorithmen wird nicht empfohlen, da Kollisionen realistisch erzwungen werden können und somit die Nützlichkeit des Digests geschwächt wird.
Wenn Sie nicht mit alten Systemen arbeiten (was unwahrscheinlich ist, da die meisten den veralteten Digest-Header erwarten und diese Spezifikation nicht verstehen), sollten Sie erwägen, auf einen Repr-Digest zu verzichten, anstatt einen mit einem unsicheren Digest-Algorithmus einzuschließen.
Beschreibung
Ein Digest-Header wurde in früheren Spezifikationen definiert, erwies sich jedoch als problematisch, da der Anwendungsbereich dessen, worauf sich der Digest bezog, nicht klar war.
Insbesondere war es schwierig zu unterscheiden, ob sich ein Digest auf die gesamte Ressourcendarstellung oder auf den spezifischen Inhalt einer HTTP-Nachricht bezog.
Daher wurden zwei separate Header (Content-Digest und Repr-Digest) spezifiziert, um HTTP-Nachrichteninhalts-Digests bzw. Ressourcendarstellungs-Digests zu übermitteln.
Beispiele
Benutzer-Agent, der einen Repr-Digest in Anfragen sendet
Im folgenden Beispiel sendet ein Benutzer-Agent einen Digest des Nachrichteninhalts mithilfe von SHA-512.
Es 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 Integrität der Nachricht zu validieren.
In Anfragen wie dem obigen Beispiel ist der Repr-Digest für den Server nützlicher, da er über die dekodierte Repräsentation berechnet wird und in verschiedenen Szenarien konsistenter wäre.
HTTP-Antwort, bei der Repr-Digest und Content-Digest übereinstimmen
Ein HTTP-Server kann die gesamte Repräsentation unkodiert in einer einzigen Nachricht senden.
In diesem Fall haben Repr-Digest und Content-Digest für dieselben Digest-Algorithmen gleiche Werte:
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
…
Content-Type: text/yaml
Content-Encoding: br
Content-Length: 38054
Content-Range: 0-38053/38054
…
[message body]
HTTP-Antworten, bei denen Repr-Digest und Content-Digest divergieren
Ein Server kann den Inhalt zur Übertragung komprimieren.
In diesem Fall wird Content-Digest von der Content-Encoding abhängen und daher einen anderen Wert als der Repr-Digest-Header in einer Antwort haben:
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:
Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809
…
Content-Type: text/html; charset=utf-8
Content-Encoding: br
…
[message body]
In einer anderen Antwort verwendet der Server eine andere Komprimierungsmethode, was zu einem neuen Content-Digest, jedoch denselben Repr-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-8
Content-Encoding: zstd
…
[message body]
Erfolgreiche HTTP-Anfrage-Antwort unter Verwendung von Want-Repr-Digest, Repr-Digest und Content-Digest
Die folgende PUT-Anfrage enthält einen Want-Repr-Digest-Header, der angibt, dass der Server einen Repr-Digest-Header mit einem sha-256-Digest einfügen sollte, wenn die Operation erfolgreich ist:
PUT /api/transact HTTP/1.1
Want-Repr-Digest: sha-256=8
Content-Type: text/json
…
[message body]
Der Server antwortet mit einer erfolgreichen 201 Created-Antwort, einschließlich der Repr-Digest- und Content-Digest-Header mit sha-256-Digests der Repräsentation bzw. des Inhalts:
HTTP/1.1 201 Created
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
Content-Encoding: br
Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
[message body]
Erfolglose HTTP-Anfrage-Antwort unter Verwendung von Repr-Digest
Im folgenden Beispiel fordert ein Benutzer-Agent eine Ressource mit einem spezifischen sha-256-Digest an:
GET /api/last-transaction HTTP/1.1
Accept: text/json
Repr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
Ein 406 Not Acceptable wird vom Server zurückgegeben, um anzuzeigen, dass die Operation aufgrund eines spezifischen Digests für die Ressource fehlgeschlagen ist.
Ein Repr-Digest-Header wird mit dem SHA-256-Digest-Wert eingefügt, der zu einer erfolgreichen Antwort führen würde, wenn der Benutzer-Agent die Anfrage mit diesem Wert wiederholte:
HTTP/1.1 406 Not Acceptable
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
…
Spezifikationen
| Spezifikation |
|---|
| Digest Fields |
Browser-Kompatibilität
Dieser Header hat keine spezifikation-definierte Browser-Integration ("Browser-Kompatibilität" ist nicht anwendbar).
Entwickler können HTTP-Header mit fetch() setzen und abrufen, um ein anwendungsspezifisches Implementierungsverhalten bereitzustellen.
Siehe auch
Content-Digest,Want-Content-Digest,Want-Repr-DigestETagContent-Encoding- Digitale Signaturen für APIs SDK-Leitfaden verwendet
Content-Digests für digitale Signaturen in HTTP-Anrufen (developer.ebay.com)