3. Representations (Darstellungen)

Da eine Ressource alles sein kann und die von HTTP bereitgestellte einheitliche Schnittstelle einem Fenster ähnelt, durch das man eine solche Sache nur durch die Kommunikation von Nachrichten an einen unabhängigen Akteur auf der anderen Seite beobachten und auf sie einwirken kann, wird eine Abstraktion benötigt, um den aktuellen oder gewünschten Zustand dieser Sache in unserer Kommunikation zu "repräsentieren" ("den Platz einzunehmen"). Diese Abstraktion wird als Darstellung (representation) [REST] bezeichnet.

Für die Zwecke von HTTP ist eine "Darstellung" (representation) eine Information, die darauf abzielt, einen vergangenen, aktuellen oder gewünschten Zustand einer bestimmten Ressource widerzuspiegeln, in einem Format, das problemlos über das Protokoll kommuniziert werden kann, und die aus einer Reihe von Darstellungsmetadaten und einem potenziell unbegrenzten Strom von Darstellungsdaten besteht.

Ein Origin-Server (origin server) kann mit mehreren Darstellungen ausgestattet sein oder diese generieren können, die jeweils darauf abzielen, den aktuellen Zustand einer Zielressource widerzuspiegeln. In solchen Fällen wird vom Origin-Server ein Algorithmus verwendet, um eine dieser Darstellungen als am besten auf eine bestimmte Anfrage anwendbar auszuwählen, normalerweise basierend auf Content Negotiation (Inhaltsverhandlung). Diese "ausgewählte Darstellung" (selected representation) wird verwendet, um die Daten und Metadaten für die Bewertung bedingter Anfragen [RFC7232] und die Konstruktion der Nutzlast für 200 (OK)- und 304 (Not Modified)-Antworten auf GET [Section 4.3.1] bereitzustellen.

3.1. Representation Metadata (Darstellungsmetadaten)

Darstellungs-Header-Felder (representation header fields) liefern Metadaten über die Darstellung. Wenn eine Nachricht einen Nutzlastkörper (payload body) enthält, beschreiben die Darstellungs-Header-Felder, wie die im Nutzlastkörper eingeschlossenen Darstellungsdaten zu interpretieren sind. In einer Antwort auf eine HEAD-Anfrage beschreiben die Darstellungs-Header-Felder die Darstellungsdaten, die im Nutzlastkörper eingeschlossen gewesen wären, wenn dieselbe Anfrage eine GET-Anfrage gewesen wäre.

3.1.1. Processing Representation Data (Verarbeitung von Darstellungsdaten)

Der Zweck von Darstellungsmetadaten besteht darin, Empfängern zu ermöglichen, zu wissen, mit welchem Format sie es zu tun haben, welche Sprache oder Sprachen die Darstellung verwendet und welche Transformationen von eingreifenden Vermittlern auf die Darstellungsdaten angewendet wurden.

3.1.1.1. Media Type (Medientyp)

HTTP verwendet Internet-Medientypen [RFC2046] in den Header-Feldern Content-Type (Section 3.1.1.5) und Accept (Section 5.3.2), um offene und erweiterbare Datentypisierung und Typverhandlung bereitzustellen. Medientypen definieren sowohl ein Datenformat als auch verschiedene Verarbeitungsmodelle: wie diese Daten gemäß jedem Kontext, in dem sie empfangen werden, zu verarbeiten sind.

media-type = type "/" subtype *( OWS ";" OWS parameter )
type       = token
subtype    = token

Dem Typ/Subtyp können Parameter in Form von Name=Wert-Paaren folgen.

parameter      = token "=" ( token / quoted-string )

Die Token für Typ, Subtyp und Parametername unterscheiden nicht zwischen Groß- und Kleinschreibung. Parameterwerte können je nach Semantik des Parameternamens zwischen Groß- und Kleinschreibung unterscheiden oder nicht. Das Vorhandensein oder Fehlen eines Parameters kann für die Verarbeitung eines Medientyps von Bedeutung sein, abhängig von seiner Definition im Medientyp-Register.

Ein Parameterwert, der der Token-Produktion entspricht, kann entweder als Token oder innerhalb einer in Anführungszeichen gesetzten Zeichenkette übertragen werden. Die in Anführungszeichen gesetzten und nicht in Anführungszeichen gesetzten Werte sind äquivalent. Beispielsweise sind die folgenden Beispiele alle äquivalent, aber das erste wird aus Konsistenzgründen bevorzugt:

text/html;charset=utf-8
text/html;charset=UTF-8
text/HTML;charset="utf-8"
text/html; charset="utf-8"

Internet-Medientypen sollten gemäß den in [BCP13] definierten Verfahren bei der IANA registriert werden.

3.1.1.2. Charset (Zeichensatz)

HTTP verwendet Zeichensatznamen, um das Zeichencodierungsschema einer textuellen Darstellung [RFC6365] anzugeben oder auszuhandeln. Ein Zeichensatz wird durch ein Token identifiziert, das nicht zwischen Groß- und Kleinschreibung unterscheidet.

charset = token

Zeichensatznamen sollten gemäß den in [RFC2978] definierten Verfahren im IANA-Register "Character Sets" (http://www.iana.org/assignments/character-sets) registriert werden.

3.1.1.3. Canonicalization and Text Defaults (Kanonisierung und Textstandards)

Internet-Medientypen werden in einer kanonischen Form registriert, um zwischen Systemen mit unterschiedlichen nativen Codierungsformaten interoperabel zu sein. Darstellungen, die über HTTP ausgewählt oder übertragen werden, sollten aus vielen der gleichen Gründe, die von den Multipurpose Internet Mail Extensions (MIME) [RFC2045] beschrieben werden, in kanonischer Form vorliegen. Die Leistungsmerkmale von E-Mail-Bereitstellungen (d. h. Speichern und Weiterleiten von Nachrichten an Peers) unterscheiden sich jedoch erheblich von denen, die für HTTP und das Web üblich sind (serverbasierte Informationsdienste). Darüber hinaus gelten die Einschränkungen von MIME zur Kompatibilität mit älteren Mail-Transfer-Protokollen nicht für HTTP (siehe Anhang A).

Die kanonische Form von MIME erfordert, dass Mediensubtypen vom Typ "text" CRLF als Textumbruch verwenden. HTTP erlaubt die Übertragung von Textmedien mit einfachem CR oder LF allein als Zeilenumbruch, wenn solche Zeilenumbrüche für eine gesamte Darstellung konsistent sind. Ein HTTP-Absender kann generieren (MAY), und ein Empfänger muss in der Lage sein zu parsen (MUST), Zeilenumbrüche in Textmedien, die aus CRLF, blankem CR oder blankem LF bestehen. Darüber hinaus sind Textmedien in HTTP nicht auf Zeichensätze beschränkt, die die Oktette 13 und 10 für CR bzw. LF verwenden. Diese Flexibilität in Bezug auf Zeilenumbrüche gilt nur für Text innerhalb einer Darstellung, der ein "text"-Medientyp zugewiesen wurde; sie gilt nicht für "multipart"-Typen oder HTTP-Elemente außerhalb des Nutzlastkörpers (z. B. Header-Felder).

Wenn eine Darstellung mit einer Inhaltscodierung (content-coding) codiert ist, sollten die zugrunde liegenden Daten in einer oben definierten Form vorliegen, bevor sie codiert werden.

3.1.1.4. Multipart Types (Mehrteilige Typen)

MIME bietet eine Reihe von "multipart"-Typen - Kapselungen einer oder mehrerer Darstellungen innerhalb eines einzelnen Nachrichtenkörpers. Alle mehrteiligen Typen teilen eine gemeinsame Syntax, wie in Section 5.1.1 von [RFC2046] definiert, und enthalten einen Boundary-Parameter als Teil des Medientypwerts. Der Nachrichtenkörper selbst ist ein Protokollelement; ein Absender muss (MUST) nur CRLF generieren, um Zeilenumbrüche zwischen Körperteilen darzustellen.

Das HTTP-Message-Framing verwendet die Multipart-Boundary nicht als Indikator für die Nachrichtenkörperlänge, obwohl sie von Implementierungen verwendet werden könnte, die die Nutzlast generieren oder verarbeiten. Beispielsweise wird der Typ "multipart/byteranges" von HTTP für die Verwendung in einigen 206 (Partial Content)-Antworten [RFC7233] definiert.

3.1.1.5. Content-Type (Inhaltstyp)

Das Header-Feld Content-Type gibt den Medientyp der zugehörigen Darstellung an: entweder die im Nachrichten-Nutzlast eingeschlossene Darstellung oder die ausgewählte Darstellung, wie durch die Nachrichtensemantik bestimmt. Der angegebene Medientyp definiert sowohl das Datenformat als auch die Art und Weise, wie diese Daten von einem Empfänger verarbeitet werden sollen, im Rahmen der empfangenen Nachrichtensemantik, nachdem alle durch Content-Encoding angegebenen Inhaltscodierungen decodiert wurden.

Content-Type = media-type

Medientypen sind in Section 3.1.1.1 definiert. Ein Beispiel für das Feld ist:

Content-Type: text/html; charset=ISO-8859-4

Ein Absender, der eine Nachricht mit einem Nutzlastkörper generiert, sollte (SHOULD) ein Content-Type-Header-Feld in dieser Nachricht generieren, es sei denn, der beabsichtigte Medientyp der eingeschlossenen Darstellung ist dem Absender unbekannt. Wenn ein Content-Type-Header-Feld nicht vorhanden ist, kann (MAY) der Empfänger entweder einen Medientyp von "application/octet-stream" ([RFC2046] Section 4.5.1) annehmen oder die Daten untersuchen, um ihren Typ zu bestimmen.

In der Praxis konfigurieren Ressourcenbesitzer ihren Origin-Server nicht immer ordnungsgemäß, um den korrekten Content-Type für eine bestimmte Darstellung bereitzustellen, mit dem Ergebnis, dass einige Clients den Inhalt der Nutzlast untersuchen und den angegebenen Typ überschreiben. Clients, die dies tun, riskieren, falsche Schlussfolgerungen zu ziehen, was zusätzliche Sicherheitsrisiken (z. B. "Privilegieneskalation") mit sich bringen könnte. Darüber hinaus ist es unmöglich, die Absicht des Absenders durch Untersuchung des Datenformats zu bestimmen: viele Datenformate entsprechen mehreren Medientypen, die sich nur in der Verarbeitungssemantik unterscheiden. Implementierern wird empfohlen, ein Mittel zur Verfügung zu stellen, um solches "Content Sniffing" zu deaktivieren, wenn es verwendet wird.

3.1.2. Encoding for Compression or Integrity (Codierung für Kompression oder Integrität)

3.1.2.1. Content Codings (Inhaltscodierungen)

Inhaltscodierungswerte (content coding values) geben eine Codierungstransformation an, die auf eine Darstellung angewendet wurde oder angewendet werden kann. Inhaltscodierungen werden hauptsächlich verwendet, um es zu ermöglichen, dass eine Darstellung komprimiert oder anderweitig nützlich transformiert wird, ohne die Identität ihres zugrunde liegenden Medientyps zu verlieren und ohne Informationsverlust. Häufig wird die Darstellung in codierter Form gespeichert, direkt übertragen und nur vom Empfänger decodiert.

content-coding   = token

Alle Inhaltscodierungswerte unterscheiden nicht zwischen Groß- und Kleinschreibung und sollten im "HTTP Content Coding Registry" (HTTP-Inhaltscodierungs-Register) registriert werden, wie in Section 8.4 definiert. Sie werden in den Header-Feldern Accept-Encoding (Section 5.3.4) und Content-Encoding (Section 3.1.2.2) verwendet.

Die folgenden Inhaltscodierungswerte werden von dieser Spezifikation definiert:

• compress (und x-compress): UNIX-"compress"-Datenformat [Welch]. Historisch; nicht für die Verwendung in neuen Anwendungen empfohlen.

• deflate: Das "zlib"-Format [RFC1950] in Kombination mit dem "deflate"-Kompressionsmechanismus [RFC1951].

• gzip (und x-gzip): LZ77-Codierung mit einem 32-Bit-CRC [RFC1952].

• identity: Die "identity"-Codierung (keine Transformation). Diese Codierung wird nur im Accept-Encoding-Header-Feld verwendet und sollte nicht (SHOULD NOT) im Content-Encoding-Header-Feld verwendet werden.

3.1.2.2. Content-Encoding (Inhaltscodierung)

Das Header-Feld Content-Encoding gibt an, welche Inhaltscodierungen auf die Darstellung angewendet wurden, über diejenigen hinaus, die dem Medientyp inhärent sind, und daher welche Decodierungsmechanismen angewendet werden müssen, um Daten im vom Content-Type-Header-Feld referenzierten Medientyp zu erhalten. Content-Encoding wird hauptsächlich verwendet, um es zu ermöglichen, dass die Daten einer Darstellung komprimiert werden, ohne die Identität ihres zugrunde liegenden Medientyps zu verlieren.

Content-Encoding = 1#content-coding

Ein Beispiel für seine Verwendung ist:

Content-Encoding: gzip

Wenn eine oder mehrere Codierungen auf eine Darstellung angewendet wurden, muss (MUST) der Absender, der die Codierungen angewendet hat, ein Content-Encoding-Header-Feld generieren, das die Inhaltscodierungen in der Reihenfolge auflistet, in der sie angewendet wurden. Zusätzliche Informationen über die Codierungsparameter können durch andere Header-Felder bereitgestellt werden, die nicht durch diese Spezifikation definiert sind.

Im Gegensatz zu Transfer-Encoding (Section 3.3 von [RFC7230]) sind die in Content-Encoding aufgelisteten Codierungen eine Eigenschaft der Darstellung; die Darstellung wird in Bezug auf die codierte Form definiert, und alle anderen Metadaten über die Darstellung beziehen sich auf die codierte Form, sofern in der Metadatendefinition nicht anders angegeben. Typischerweise wird die Darstellung erst unmittelbar vor dem Rendern oder einer analogen Verwendung decodiert.

Wenn der Medientyp eine inhärente Codierung enthält, wie z. B. ein Datenformat, das immer komprimiert ist, würde diese Codierung nicht in Content-Encoding wiederholt werden, selbst wenn sie zufällig derselbe Algorithmus wie eine der Inhaltscodierungen ist. Eine solche Inhaltscodierung würde nur aufgelistet werden, wenn sie aus irgendeinem bizarren Grund ein zweites Mal angewendet wird, um die Darstellung zu bilden. Ebenso könnte sich ein Origin-Server dafür entscheiden, dieselben Daten als mehrere Darstellungen zu veröffentlichen, die sich nur darin unterscheiden, ob die Codierung als Teil von Content-Type oder Content-Encoding definiert ist, da einige User-Agents sich in ihrer Handhabung jeder Antwort unterschiedlich verhalten (z. B. Öffnen eines "Speichern unter..."-Dialogs anstelle der automatischen Dekomprimierung und Darstellung von Inhalten).

Ein Origin-Server kann (MAY) mit einem Statuscode 415 (Unsupported Media Type) antworten, wenn eine Darstellung in der Anfragenachricht eine Inhaltscodierung aufweist, die nicht akzeptabel ist.

3.1.3. Audience Language (Zielgruppensprache)

3.1.3.1. Language Tags (Sprach-Tags)

Ein Sprach-Tag (language tag), wie in [RFC5646] definiert, identifiziert eine natürliche Sprache, die von Menschen gesprochen, geschrieben oder auf andere Weise vermittelt wird, um Informationen an andere Menschen zu kommunizieren. Computersprachen sind ausdrücklich ausgeschlossen.

HTTP verwendet Sprach-Tags in den Header-Feldern Accept-Language und Content-Language. Accept-Language verwendet die breitere language-range-Produktion, die in Section 5.3.5 definiert ist, während Content-Language die unten definierte language-tag-Produktion verwendet.

language-tag = <Language-Tag, see [RFC5646], Section 2.1>

Ein Sprach-Tag ist eine Sequenz von einem oder mehreren Sub-Tags, die nicht zwischen Groß- und Kleinschreibung unterscheiden und jeweils durch ein Bindestrichzeichen ("-", %x2D) getrennt sind. In den meisten Fällen besteht ein Sprach-Tag aus einem primären Sprach-Sub-Tag, das eine breite Familie verwandter Sprachen identifiziert (z. B. "en" = Englisch), gefolgt von optional einer Reihe von Sub-Tags, die die Reichweite dieser Sprache verfeinern oder eingrenzen (z. B. "en-CA" = die Varietät des Englischen, wie sie in Kanada kommuniziert wird). Leerzeichen sind innerhalb eines Sprach-Tags nicht erlaubt. Beispiel-Tags umfassen:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Siehe [RFC5646] für weitere Informationen.

3.1.3.2. Content-Language (Inhaltssprache)

Das Header-Feld Content-Language beschreibt die natürliche(n) Sprache(n) des beabsichtigten Publikums für die Darstellung. Beachten Sie, dass dies möglicherweise nicht allen Sprachen entspricht, die innerhalb der Darstellung verwendet werden.

Content-Language = 1#language-tag

Sprach-Tags sind in Section 3.1.3.1 definiert. Der Hauptzweck von Content-Language besteht darin, einem Benutzer zu ermöglichen, Darstellungen gemäß der eigenen bevorzugten Sprache des Benutzers zu identifizieren und zu unterscheiden. Wenn der Inhalt also nur für ein dänischsprachiges Publikum bestimmt ist, lautet das entsprechende Feld:

Content-Language: da

Wenn kein Content-Language angegeben ist, ist standardmäßig der Inhalt für alle Sprachzielgruppen bestimmt. Dies könnte bedeuten, dass der Absender ihn nicht als spezifisch für eine natürliche Sprache betrachtet, oder dass der Absender nicht weiß, für welche Sprache er bestimmt ist.

Mehrere Sprachen können (MAY) für Inhalte aufgelistet werden, die für mehrere Zielgruppen bestimmt sind. Zum Beispiel würde eine Darstellung des "Treaty of Waitangi" (Vertrag von Waitangi), die gleichzeitig in den ursprünglichen Māori- und englischen Versionen präsentiert wird, erfordern:

Content-Language: mi, en

Nur weil jedoch mehrere Sprachen innerhalb einer Darstellung vorhanden sind, bedeutet dies nicht, dass sie für mehrere sprachliche Zielgruppen bestimmt ist. Ein Beispiel wäre ein Sprachanfänger-Primer wie "A First Lesson in Latin" (Eine erste Lektion in Latein), der eindeutig für die Verwendung durch ein englischsprachiges Publikum bestimmt ist. In diesem Fall sollte Content-Language nur "en" enthalten.

Content-Language kann (MAY) auf jeden Medientyp angewendet werden - es ist nicht auf Textdokumente beschränkt.

3.1.4. Identification (Identifikation)

3.1.4.1. Identifying a Representation (Identifizierung einer Darstellung)

Wenn eine vollständige oder teilweise Darstellung in einer Nachrichten-Nutzlast übertragen wird, ist es oft wünschenswert, dass der Absender einen Identifikator für eine Ressource bereitstellt, die dieser Darstellung entspricht, oder dass der Empfänger ihn bestimmt.

Für eine Anfragenachricht:

• Wenn die Anfrage ein Content-Location-Header-Feld hat, behauptet der Absender, dass die Nutzlast eine Darstellung der durch den Content-Location-Feldwert identifizierten Ressource ist. Eine solche Behauptung kann jedoch nicht als vertrauenswürdig angesehen werden, es sei denn, sie kann durch andere Mittel (nicht durch diese Spezifikation definiert) verifiziert werden. Die Informationen könnten dennoch für Revisionsverlaufslinks nützlich sein.

• Andernfalls ist die Nutzlast nicht identifiziert.

Für eine Antwortnachricht werden die folgenden Regeln in der Reihenfolge angewendet, bis eine Übereinstimmung gefunden wird:

1. Wenn die Anfragemethode GET oder HEAD ist und der Antwortstatuscode 200 (OK), 204 (No Content), 206 (Partial Content) oder 304 (Not Modified) ist, ist die Nutzlast eine Darstellung der durch den effektiven Anfrage-URI (Section 5.5 von [RFC7230]) identifizierten Ressource.

2. Wenn die Anfragemethode GET oder HEAD ist und der Antwortstatuscode 203 (Non-Authoritative Information) ist, ist die Nutzlast eine potenziell modifizierte oder erweiterte Darstellung der Zielressource, wie von einem Vermittler bereitgestellt.

3. Wenn die Antwort ein Content-Location-Header-Feld hat und sein Feldwert ein Verweis auf denselben URI wie der effektive Anfrage-URI ist, ist die Nutzlast eine Darstellung der durch den effektiven Anfrage-URI identifizierten Ressource.

4. Wenn die Antwort ein Content-Location-Header-Feld hat und sein Feldwert ein Verweis auf einen URI ist, der sich vom effektiven Anfrage-URI unterscheidet, behauptet der Absender, dass die Nutzlast eine Darstellung der durch den Content-Location-Feldwert identifizierten Ressource ist. Eine solche Behauptung kann jedoch nicht als vertrauenswürdig angesehen werden, es sei denn, sie kann durch andere Mittel (nicht durch diese Spezifikation definiert) verifiziert werden.

5. Andernfalls ist die Nutzlast nicht identifiziert.

3.1.4.2. Content-Location (Inhaltsposition)

Das Header-Feld Content-Location verweist auf einen URI, der als Identifikator für eine spezifische Ressource verwendet werden kann, die der Darstellung in der Nutzlast dieser Nachricht entspricht. Mit anderen Worten, wenn man zum Zeitpunkt der Generierung dieser Nachricht eine GET-Anfrage an diesen URI stellen würde, würde eine 200 (OK)-Antwort dieselbe Darstellung enthalten, die als Nutzlast in dieser Nachricht eingeschlossen ist.

Content-Location = absolute-URI / partial-URI

Der Content-Location-Wert ist kein Ersatz für den effektiven Anfrage-URI (Section 5.5 von [RFC7230]). Es handelt sich um Darstellungsmetadaten. Es hat dieselbe Syntax und Semantik wie das Header-Feld desselben Namens, das für MIME-Körperteile in Section 4 von [RFC2557] definiert ist. Sein Auftreten in einer HTTP-Nachricht hat jedoch einige besondere Implikationen für HTTP-Empfänger.

Wenn Content-Location in einer 2xx (Successful)-Antwortnachricht enthalten ist und sein Wert (nach Konvertierung in absolute Form) auf einen URI verweist, der mit dem effektiven Anfrage-URI identisch ist, kann (MAY) der Empfänger die Nutzlast als aktuelle Darstellung dieser Ressource zum Zeitpunkt betrachten, der durch das Nachrichtenursprungsdatum angegeben ist. Für eine GET (Section 4.3.1)- oder HEAD (Section 4.3.2)-Anfrage ist dies dasselbe wie die Standardsemantik, wenn kein Content-Location vom Server bereitgestellt wird. Für eine zustandsändernde Anfrage wie PUT (Section 4.3.4) oder POST (Section 4.3.3) impliziert dies, dass die Antwort des Servers die neue Darstellung dieser Ressource enthält, wodurch sie von Darstellungen unterschieden wird, die möglicherweise nur über die Aktion berichten (z. B. "Es hat funktioniert!"). Dies ermöglicht es Authoring-Anwendungen, ihre lokalen Kopien zu aktualisieren, ohne dass eine nachfolgende GET-Anfrage erforderlich ist.

Wenn Content-Location in einer 2xx (Successful)-Antwortnachricht enthalten ist und sein Feldwert auf einen URI verweist, der sich vom effektiven Anfrage-URI unterscheidet, behauptet der Origin-Server, dass der URI ein Identifikator für eine andere Ressource ist, die der eingeschlossenen Darstellung entspricht. Eine solche Behauptung kann nur dann als vertrauenswürdig angesehen werden, wenn beide Identifikatoren denselben Ressourcenbesitzer teilen, was nicht programmgesteuert über HTTP bestimmt werden kann.

• Für eine Antwort auf eine GET- oder HEAD-Anfrage ist dies ein Hinweis darauf, dass der effektive Anfrage-URI auf eine Ressource verweist, die der Content Negotiation unterliegt, und der Content-Location-Feldwert ein spezifischerer Identifikator für die ausgewählte Darstellung ist.

• Für eine 201 (Created)-Antwort auf eine POST-Anfrage ist der Content-Location-Feldwert ein Verweis auf eine Ressource, die den übermittelten Daten entspricht (d. h. eine von der durch den effektiven Anfrage-URI identifizierten Ressource verschiedene Ressource).

• Andernfalls zeigt ein solcher Content-Location an, dass diese Nutzlast eine Darstellung einer anderen Ressource als des Ziels der Anfragenachricht ist und keine weitere Bedeutung für HTTP hat.

Wenn Content-Location in einer Antwortnachricht enthalten ist und die Darstellung aus mehreren Teilen besteht, wie durch einen Content-Type von "multipart/*" angegeben, kann (MAY) jeder Teil seinen eigenen Content-Location haben, um die Ressource anzugeben, die diesem Teil entspricht. Andernfalls gilt Content-Location nur für die Nutzlast als Ganzes.

3.2. Representation Data (Darstellungsdaten)

Die mit einer HTTP-Nachricht verbundenen Darstellungsdaten werden entweder als Nutzlastkörper der Nachricht bereitgestellt oder durch die Nachrichtensemantik und den effektiven Anfrage-URI referenziert. Die Darstellungsdaten liegen in einem Format und einer Codierung vor, die durch die Darstellungsmetadaten-Header-Felder definiert sind.

Der Datentyp der Darstellungsdaten wird über die Header-Felder Content-Type und Content-Encoding bestimmt. Diese definieren ein zweischichtiges, geordnetes Codierungsmodell:

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Payload Semantics (Nutzlastsemantik)

Einige HTTP-Nachrichten übertragen eine vollständige oder teilweise Darstellung als Nachrichten-"Nutzlast" (payload). In einigen Fällen kann eine Nutzlast nur die Header-Felder der zugehörigen Darstellung (z. B. Antworten auf HEAD) oder nur einige Teil(e) der Darstellungsdaten (z. B. den Statuscode 206 (Partial Content)) enthalten.

Der Zweck einer Nutzlast in einer Anfrage wird durch die Methodensemantik definiert. Zum Beispiel repräsentiert eine Darstellung in der Nutzlast einer PUT-Anfrage (Section 4.3.4) den gewünschten Zustand der Zielressource, wenn die Anfrage erfolgreich angewendet wird, während eine Darstellung in der Nutzlast einer POST-Anfrage (Section 4.3.3) Informationen repräsentiert, die von der Zielressource verarbeitet werden sollen.

In einer Antwort wird der Zweck der Nutzlast sowohl durch die Anfragemethode als auch durch den Antwortstatuscode definiert. Zum Beispiel repräsentiert die Nutzlast einer 200 (OK)-Antwort auf GET (Section 4.3.1) den aktuellen Zustand der Zielressource, wie zum Zeitpunkt des Nachrichtenursprungsdatums (Section 7.1.1.2) beobachtet, während die Nutzlast desselben Statuscodes in einer Antwort auf POST entweder das Verarbeitungsergebnis oder den neuen Zustand der Zielressource nach Anwendung der Verarbeitung repräsentieren kann.

Eine Nutzlast wird in den folgenden Fällen als "vollständig" (complete) betrachtet:

• der gesamte Header-Abschnitt wurde empfangen und die angegebene Nutzlastkörperlänge ist null;

• eine gestufte Nutzlast (chunked payload) ist vollständig, wenn der gestufte Körperteil vollständig ist (wie durch den Chunk der Länge null und das abschließende CRLF angezeigt);

• eine unbekannte Nutzlastlänge ist vollständig, wenn die Verbindung geschlossen wird.

3.4. Content Negotiation (Inhaltsverhandlung)

Wenn Antworten Nutzlastinformationen vermitteln, ob sie einen Erfolg oder einen Fehler anzeigen, hat der Origin-Server oft verschiedene Möglichkeiten, diese Informationen darzustellen; zum Beispiel in verschiedenen Formaten, Sprachen oder Codierungen. Ebenso können verschiedene Benutzer oder User-Agents unterschiedliche Fähigkeiten, Merkmale oder Präferenzen haben, die beeinflussen könnten, welche Darstellung unter den verfügbaren am besten zu liefern wäre. Aus diesem Grund bietet HTTP Mechanismen für die Inhaltsverhandlung.

Diese Spezifikation definiert drei Muster der Inhaltsverhandlung, die im Protokoll sichtbar gemacht werden können: "proaktiv" (proactive), bei der der Server die Darstellung basierend auf den erklärten Präferenzen des User-Agents auswählt; "reaktiv" (reactive), bei der der Server eine Liste von Darstellungen zur Auswahl durch den User-Agent bereitstellt; und "Anfrage-Inhalt" (request content), bei der der User-Agent die Darstellung für eine Anfrage-Nutzlast auswählt. Andere Muster der Inhaltsverhandlung umfassen "bedingter Inhalt" (conditional content), bei dem die Darstellung aus mehreren Teilen besteht, die basierend auf User-Agent-Parametern selektiv gerendert werden, "aktiver Inhalt" (active content), bei dem die Darstellung ein Skript enthält, das zusätzliche (spezifischere) Anfragen basierend auf den User-Agent-Merkmalen stellt, und "Transparente Inhaltsverhandlung" (Transparent Content Negotiation) ([RFC2295]), bei der die Inhaltsauswahl von einem Vermittler durchgeführt wird. Diese Muster schließen sich nicht gegenseitig aus, und jedes hat Kompromisse in Bezug auf Anwendbarkeit und Praktikabilität.

Beachten Sie, dass HTTP in allen Fällen die Ressourcensemantik nicht kennt. Die Konsistenz, mit der ein Origin-Server auf Anfragen reagiert, im Laufe der Zeit und über die variierenden Dimensionen der Inhaltsverhandlung hinweg, und damit die "Gleichheit" der beobachteten Darstellungen einer Ressource im Laufe der Zeit, wird vollständig durch die Entität oder den Algorithmus bestimmt, die diese Antworten auswählen oder generieren. HTTP achtet nicht auf den Mann hinter dem Vorhang.

3.4.1. Proactive Negotiation (Proaktive Verhandlung)

Wenn Content-Negotiation-Präferenzen vom User-Agent in einer Anfrage gesendet werden, um einen auf dem Server befindlichen Algorithmus zu ermutigen, die bevorzugte Darstellung auszuwählen, wird dies als proaktive Verhandlung (proactive negotiation) (auch bekannt als servergesteuerte Verhandlung) bezeichnet. Die Auswahl basiert auf den verfügbaren Darstellungen für eine Antwort (den Dimensionen, über die sie variieren kann, wie Sprache, Inhaltscodierung usw.) im Vergleich zu verschiedenen in der Anfrage bereitgestellten Informationen, einschließlich sowohl der expliziten Verhandlungsfelder von Section 5.3 als auch impliziter Merkmale, wie der Netzwerkadresse des Clients oder Teilen des User-Agent-Felds.

Proaktive Verhandlung ist vorteilhaft, wenn der Algorithmus zur Auswahl aus den verfügbaren Darstellungen schwer für einen User-Agent zu beschreiben ist oder wenn der Server seine "beste Schätzung" zusammen mit der ersten Antwort an den User-Agent senden möchte (in der Hoffnung, die Round-Trip-Verzögerung einer nachfolgenden Anfrage zu vermeiden, wenn die "beste Schätzung" für den Benutzer gut genug ist). Um die Schätzung des Servers zu verbessern, kann (MAY) ein User-Agent Anfrage-Header-Felder senden, die seine Präferenzen beschreiben.

Proaktive Verhandlung hat ernsthafte Nachteile:

• Es ist für den Server unmöglich, genau zu bestimmen, was für einen bestimmten Benutzer "am besten" sein könnte, da dies vollständige Kenntnis sowohl der Fähigkeiten des User-Agents als auch der beabsichtigten Verwendung der Antwort erfordern würde (z. B. möchte der Benutzer sie auf dem Bildschirm ansehen oder auf Papier drucken?);

• Wenn der User-Agent seine Fähigkeiten in jeder Anfrage beschreiben muss, kann dies sowohl sehr ineffizient sein (angesichts der Tatsache, dass nur ein kleiner Prozentsatz der Antworten mehrere Darstellungen hat) als auch ein potenzielles Risiko für die Privatsphäre des Benutzers darstellen;

• Es verkompliziert die Implementierung eines Origin-Servers und die Algorithmen zur Generierung von Antworten auf eine Anfrage; und,

• Es schränkt die Wiederverwendbarkeit von Antworten für Shared Caching ein.

Ein User-Agent kann sich nicht darauf verlassen, dass proaktive Verhandlungspräferenzen konsistent eingehalten werden, da der Origin-Server möglicherweise keine proaktive Verhandlung für die angeforderte Ressource implementiert oder entscheiden kann, dass das Senden einer Antwort, die nicht den Präferenzen des User-Agents entspricht, besser ist als das Senden einer 406 (Not Acceptable)-Antwort.

Ein Vary-Header-Feld (Section 7.1.4) wird oft in einer Antwort gesendet, die proaktiver Verhandlung unterliegt, um anzuzeigen, welche Teile der Anfrageinformationen im Auswahlalgorithmus verwendet wurden.

3.4.2. Reactive Negotiation (Reaktive Verhandlung)

Bei reaktiver Verhandlung (reactive negotiation) (auch bekannt als agentengesteuerte Verhandlung) wird die Auswahl der besten Antwortdarstellung (unabhängig vom Statuscode) vom User-Agent durchgeführt, nachdem eine anfängliche Antwort vom Origin-Server empfangen wurde, die eine Liste von Ressourcen für alternative Darstellungen enthält. Wenn der User-Agent mit der anfänglichen Antwortdarstellung nicht zufrieden ist, kann er eine GET-Anfrage an eine oder mehrere der alternativen Ressourcen stellen, die basierend auf den in der Liste enthaltenen Metadaten ausgewählt wurden, um eine andere Form der Darstellung für diese Antwort zu erhalten. Die Auswahl von Alternativen kann automatisch vom User-Agent oder manuell vom Benutzer durch Auswahl aus einem generierten (möglicherweise Hypertext-)Menü durchgeführt werden.

Beachten Sie, dass sich das oben Gesagte auf Darstellungen der Antwort im Allgemeinen bezieht, nicht auf Darstellungen der Ressource. Die alternativen Darstellungen sind nicht notwendigerweise Darstellungen derselben Ressource, obwohl sie es sein könnten.

Ein Server kann sich dafür entscheiden, keine anfängliche Darstellung außer der Liste von Alternativen zu senden und damit anzuzeigen, dass reaktive Verhandlung durch den User-Agent bevorzugt wird. Beispielsweise enthalten die in Antworten mit den Statuscodes 300 (Multiple Choices) und 406 (Not Acceptable) aufgeführten Alternativen Informationen über die verfügbaren Darstellungen, damit der Benutzer oder User-Agent reagieren kann, indem er eine Auswahl trifft.

Reaktive Verhandlung ist vorteilhaft, wenn die Antwort über häufig verwendete Dimensionen (wie Typ, Sprache oder Codierung) variieren würde, wenn der Origin-Server nicht in der Lage ist, die Fähigkeiten eines User-Agents durch Untersuchung der Anfrage zu bestimmen, und im Allgemeinen, wenn öffentliche Caches verwendet werden, um die Serverlast zu verteilen und die Netzwerknutzung zu reduzieren.

Reaktive Verhandlung leidet unter den Nachteilen der Übertragung einer Liste von Alternativen an den User-Agent, was die vom Benutzer wahrgenommene Latenz verringert, wenn sie im Header-Abschnitt übertragen wird, und erfordert eine zweite Anfrage, um eine alternative Darstellung zu erhalten. Darüber hinaus definiert diese Spezifikation keinen Mechanismus zur Unterstützung der automatischen Auswahl, obwohl sie nicht verhindert, dass ein solcher Mechanismus als Erweiterung entwickelt wird.

3.4.3. Request Content Negotiation (Anfrage-Inhaltsverhandlung)

Wenn Content-Negotiation-Präferenzen in der Antwort eines Servers an einen Client gesendet werden, kann der Client diese Präferenzen verwenden, um zu bestimmen, welche Darstellung für nachfolgende Anfragen an diese Ressource am besten ist. Dies wird als Anfrage-Inhaltsverhandlung (request content negotiation) (auch bekannt als "Inhaltsverhandlung als Dienstgüte") bezeichnet.

Zum Beispiel könnte ein Accept-Header-Feld in einer 415 (Unsupported Media Type)-Antwort angeben, welche Medientypen in einer PUT-Anfrage an diese Ressource akzeptiert werden, oder das Accept-Language-Feld einer Antwort könnte die Sprachpräferenzen des Dienstes angeben.

---