Repr-Digest header

Der HTTP-Repr-Digest-Anforderungs- 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, sobald sie empfangen und rekonstruiert wurde.

Die ausgewählte Repräsentation ist das spezifische Format einer Ressource, das durch die Inhaltsverhandlung gewählt wurde. Details über die Repräsentation können aus Repräsentations-Headern wie Content-Language, Content-Type und Content-Encoding bestimmt werden.

Der Repräsentations-Digest bezieht sich auf die gesamte Repräsentation, nicht auf die Kodierung oder Stückelung der Nachrichten, die verwendet werden, um sie zu senden. Ein Content-Digest bezieht sich auf den Inhalt einer spezifischen Nachricht und hat unterschiedliche Werte basierend auf dem Content-Encoding und Content-Range jeder Nachricht.

Header-Typ Repräsentations-Header
Verbotener Anforderungs-Header Nein

Syntax

http
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-512 und sha-256. Die unsicheren (veralteten) registrierten Digest-Algorithmen sind: md5, sha (SHA-1), unixsum, unixcksum, adler (ADLER32) und crc32c.

<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 und sha-256 verwenden Base64-Kodierung, während einige ältere Digest-Algorithmen wie unixsum eine dezimale Ganzzahl verwenden. Im Gegensatz zu früheren Entwürfen der Spezifikation sind die standard-base64-kodierten Digest-Bytes in Doppelpunkte (:, ASCII 0x3A) eingeschlossen, als Teil der Dictionary-Syntax.

Die Verwendung unsicherer Digest-Algorithmen wird nicht empfohlen, da Kollisionen realistisch erzwungen werden können und damit die Nützlichkeit des Digests geschwächt wird. Es sei denn, Sie arbeiten mit Altsystemen (was unwahrscheinlich ist, da die meisten den veralteten Digest-Header erwarten und diese Spezifikation nicht verstehen), sollte erwogen werden, einen Repr-Digest nicht einzuschließen, anstatt ihn mit einem unsicheren Digest-Algorithmus zu verwenden.

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 Ressourcenrepräsentation oder auf den spezifischen Inhalt einer HTTP-Nachricht bezieht. Daher wurden zwei separate Header spezifiziert (Content-Digest und Repr-Digest), um HTTP-Nachrichteninhalts-Digests bzw. Ressourcenrepräsentations-Digests zu vermitteln.

Beispiele

Benutzer-Agent sendet einen Repr-Digest in Anfragen

Im folgenden Beispiel sendet ein Benutzer-Agent einen Digest des Nachrichteninhalts unter Verwendung von SHA-512. Es sendet sowohl einen Content-Digest als auch einen Repr-Digest, die sich aufgrund des Content-Encoding voneinander unterscheiden:

http
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 Nachrichtenintegrität zu validieren. In Anfragen wie im obigen Beispiel ist der Repr-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 der Repr-Digest und Content-Digest übereinstimmen

Ein HTTP-Server kann die gesamte Repräsentation in einer einzigen Nachricht unkomprimiert senden. In diesem Fall haben Repr-Digest und Content-Digest gleiche Werte für die gleichen Digest-Algorithmen:

http
…
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 auseinandergehen

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

http
…
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, aber gleichen Repr-Digest-Digests führt:

http
…
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

Der folgende PUT-Request enthält einen Want-Repr-Digest-Header, was darauf hinweist, dass der Server einen Repr-Digest-Header mit einem sha-256-Digest einschließen sollte, wenn die Aktion erfolgreich ist:

http
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, die Repr-Digest- und Content-Digest-Header mit sha-256-Digests der Repräsentation bzw. des Inhalts enthält:

http
HTTP/1.1 201 Created
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
Content-Encoding: br
Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…

[message body]

Fehlgeschlagene HTTP-Anfrage-Antwort unter Verwendung von Repr-Digest

Im folgenden Nachricht fordert ein Benutzer-Agent eine Ressource mit einem bestimmten sha-256-Digest an:

http
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 bestimmten Digests für die Ressource fehlgeschlagen ist. Ein Repr-Digest-Header wird mit dem SHA-256-Digest-Wert enthalten, der zu einer erfolgreichen Antwort führen würde, wenn der Benutzer-Agent die Anfrage mit diesem Wert wiederholt:

http
HTTP/1.1 406 Not Acceptable
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
…

Spezifikationen

Specification
Digest Fields

Browser-Kompatibilität

Dieser Header hat keine spezifikationsdefinierte Browser-Integration (die "Browser-Kompatibilität" gilt nicht). Entwickler können HTTP-Header mit fetch() setzen und abrufen, um anwendungsspezifisches Implementierungsverhalten bereitzustellen.

Siehe auch