Zum Hauptinhalt springen

3. Das Repr-Digest-Feld

Das HTTP-Feld Repr-Digest kann in Anfragen und Antworten verwendet werden, um Digests zu kommunizieren, die unter Verwendung eines Hashing-Algorithmus berechnet werden, der auf die gesamten ausgewählten Repräsentationsdaten angewendet wird (siehe Abschnitt 8.1 von [HTTP]).

Repräsentationen berücksichtigen die Auswirkung der HTTP-Semantik auf Nachrichten. Beispielsweise kann der Inhalt durch Bereichsanfragen oder Methoden wie HEAD beeinflusst werden, während die Art und Weise, wie der Inhalt "on the wire" übertragen wird, von anderen Transformationen abhängt (z. B. Transfercodierungen für HTTP/1.1; siehe Abschnitt 6.1 von [HTTP/1.1]). Um HTTP-Repräsentationskonzepte zu veranschaulichen, werden in Anhang A mehrere Beispiele bereitgestellt.

Wenn eine Nachricht keine Repräsentationsdaten enthält, ist es dennoch möglich zu behaupten, dass keine Repräsentationsdaten gesendet wurden, indem der Digest auf einer leeren Zeichenfolge berechnet wird (siehe Abschnitt 6.3).

Repr-Digest ist ein Wörterbuch (siehe Abschnitt 3.2 von [STRUCTURED-FIELDS]), wobei jedes:

  • Schlüssel den Hashing-Algorithmus (siehe Abschnitt 5) übermittelt, der zur Berechnung des Digests verwendet wird;

  • Wert eine Bytesequenz ist, die eine codierte Version der Byte-Ausgabe übermittelt, die durch die Digest-Berechnung erzeugt wurde.

Zum Beispiel:

HINWEIS: '' Zeilenumbruch gemäß RFC 8792

Repr-Digest: \
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

Der Wörterbuchtyp kann verwendet werden, um mehrere Digests anzuhängen, die unter Verwendung unterschiedlicher Hashing-Algorithmen berechnet wurden, um eine Population von Endpunkten mit unterschiedlichen oder sich entwickelnden Fähigkeiten zu unterstützen. Ein solcher Ansatz könnte Übergänge weg von schwächeren Algorithmen unterstützen (siehe Abschnitt 6.6).

HINWEIS: '' Zeilenumbruch gemäß RFC 8792

Repr-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

Ein Empfänger KANN einen oder alle Digests ignorieren. Anwendungsspezifisches Verhalten oder lokale Richtlinien KÖNNEN zusätzliche Einschränkungen für die Verarbeitungs- und Validierungspraktiken der übermittelten Digests festlegen. Die Sicherheitsüberlegungen decken einige der Probleme im Zusammenhang mit dem Ignorieren von Digests (siehe Abschnitt 6.6) und der Validierung mehrerer Digests (siehe Abschnitt 6.7) ab.

Ein Absender KANN einen Digest senden, ohne zu wissen, ob der Empfänger einen bestimmten Hashing-Algorithmus unterstützt. Ein Absender KANN einen Digest senden, wenn er weiß, dass der Empfänger ihn ignorieren wird.

Repr-Digest kann in einem Trailer-Abschnitt gesendet werden. In diesem Fall KANN Repr-Digest in den Header-Abschnitt zusammengeführt werden; siehe Abschnitt 6.5.1 von [HTTP].

3.1. Verwendung von Repr-Digest in zustandsändernden Anfragen​

Wenn die in einer zustandsändernden Anfrage enthaltene Repräsentation die Zielressource nicht beschreibt, MUSS der Repräsentations-Digest auf den Repräsentationsdaten berechnet werden. Dies ist die einzig mögliche Wahl, da der Repräsentations-Digest vollständige Repräsentationsmetadaten erfordert (siehe Abschnitt 3).

In Antworten,

  • wenn die Repräsentation den Status der Anfrage beschreibt, MUSS Repr-Digest auf der enthaltenen Repräsentation berechnet werden (siehe Anhang B.8);

  • wenn es eine referenzierte Ressource gibt, MUSS Repr-Digest auf der ausgewählten Repräsentation der referenzierten Ressource berechnet werden, auch wenn diese von der Zielressource verschieden ist. Dies kann dazu führen, dass Repr-Digest auf der enthaltenen Repräsentation berechnet wird oder auch nicht.

Der letztere Fall erfolgt gemäß der HTTP-Semantik der gegebenen Methode, beispielsweise unter Verwendung des Content-Location-Header-Feldes (siehe Abschnitt 8.7 von [HTTP]). Im Gegensatz dazu beeinflusst das Location-Header-Feld Repr-Digest nicht, da es keine Repräsentationsmetadaten sind.

Beispielsweise wird in PATCH-Anfragen der Repräsentations-Digest auf dem Patch-Dokument berechnet, da sich die Repräsentationsmetadaten auf das Patch-Dokument und nicht auf die Zielressource beziehen (siehe Abschnitt 2 von [PATCH]). In Antworten hingegen wird der Repräsentations-Digest auf der ausgewählten Repräsentation der gepatchten Ressource berechnet.

3.2. Repr-Digest und Content-Location in Antworten​

Wenn eine zustandsändernde Methode das Content-Location-Header-Feld zurückgibt, bezieht sich die enthaltene Repräsentation auf die durch ihren Wert identifizierte Ressource, und Repr-Digest wird entsprechend berechnet. Ein Beispiel wird in Anhang B.7 gegeben.

Letztes Update am