3. Protocol Parameters (Protokollparameter)
3.1 HTTP Version (HTTP-Version)
HTTP verwendet ein "<major>.<minor>"-Nummerierungsschema, um Versionen des Protokolls anzuzeigen. Die Protokollversionspolitik soll es dem Absender ermöglichen, das Format einer Nachricht und seine Fähigkeit anzuzeigen, weitere HTTP-Kommunikation zu verstehen, anstatt der durch diese Kommunikation erlangten Funktionen. Keine Änderung wird an der Versionsnummer für Ergänzungen zu Nachrichtenkomponenten vorgenommen, die das Kommunikationsverhalten nicht beeinflussen oder nur zu erweiterbaren Feldwerten hinzufügen. Die <minor>-Nummer wird erhöht, wenn die am Protokoll vorgenommenen Änderungen Funktionen hinzufügen, die den allgemeinen Nachrichtenanalyse-Algorithmus nicht ändern, aber möglicherweise zur Nachrichtensemantik hinzufügen und zusätzliche Fähigkeiten des Absenders implizieren. Die <major>-Nummer wird erhöht, wenn das Format von Nachrichten im Protokoll geändert wird. Siehe RFC 2145 [36] für eine vollständigere Erklärung.
Die Version einer HTTP-Nachricht wird durch ein HTTP-Version-Feld in der ersten Zeile der Nachricht angegeben.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Beachten Sie, dass die Haupt- und Nebenversionsnummern als separate Ganzzahlen behandelt werden müssen (MUST), und jede Versionsnummer kann (MAY) über eine einzelne Ziffer hinaus erhöht werden. Daher ist HTTP/2.4 eine niedrigere Version als HTTP/2.13, die wiederum niedriger als HTTP/12.3 ist. Führende Nullen müssen (MUST) von Empfängern ignoriert werden und dürfen nicht (MUST NOT) gesendet werden.
Eine Anwendung, die eine Anforderungs- oder Antwortnachricht mit "HTTP/1.1" als HTTP-Version sendet, muss (MUST) mindestens bedingt mit dieser Spezifikation konform sein. Anwendungen, die mindestens bedingt mit dieser Spezifikation konform sind, sollten (SHOULD) eine HTTP-Version von "HTTP/1.1" in ihren Nachrichten verwenden und müssen (MUST) dies für jede Nachricht tun, die nicht mit HTTP/1.0 kompatibel ist. Weitere Details darüber, wann ein bestimmter HTTP-Version-Wert gesendet werden soll, finden Sie in RFC 2145 [36].
Die HTTP-Version einer Anwendung ist die höchste HTTP-Version, mit der die Anwendung mindestens bedingt konform ist.
Proxy- und Gateway-Anwendungen müssen vorsichtig sein, wenn sie Nachrichten einer anderen Protokollversion als der der Anwendung weiterleiten. Da die Protokollversion die Protokollfähigkeit des Absenders anzeigt, darf ein Proxy/Gateway keine (MUST NOT) Nachricht mit einem Versionsindikator senden, der größer als seine tatsächliche Version ist. Wenn eine Anforderung höherer Version empfangen wird, muss (MUST) der Proxy/Gateway entweder die Anforderungsversion herabstufen, mit einem Fehler antworten oder zum Tunnelverhalten wechseln.
Aufgrund von Interoperabilitätsproblemen mit HTTP/1.0-Proxies, die seit der Veröffentlichung von RFC 2068 [33] entdeckt wurden, müssen (MUST) Caching-Proxies, können (MAY) Gateways und dürfen nicht (MUST NOT) Tunnel die Anforderung auf die höchste von ihnen unterstützte Version upgraden. Die Antwort des Proxys/Gateways auf diese Anforderung muss (MUST) in derselben Hauptversion wie die Anforderung sein.
Hinweis: Die Konvertierung zwischen HTTP-Versionen kann die Änderung von Header-Feldern umfassen, die von den beteiligten Versionen erforderlich oder verboten sind.
3.2 Uniform Resource Identifiers (Einheitliche Ressourcenkennungen)
URIs haben viele Namen: WWW-Adressen, Universal Document Identifiers, Universal Resource Identifiers [3], und schließlich die Kombination von Uniform Resource Locators (URL) [4] und Names (URN) [20]. Was HTTP betrifft, sind Uniform Resource Identifiers einfach formatierte Zeichenfolgen, die eine Ressource durch Namen, Standort oder jede andere Eigenschaft identifizieren.
3.2.1 General Syntax (Allgemeine Syntax)
URIs in HTTP können in absoluter Form oder relativ zu einem bekannten Basis-URI [11] dargestellt werden, abhängig vom Kontext ihrer Verwendung. Die Unterscheidung zwischen diesen beiden Formen besteht darin, dass absolute URIs immer mit einem Schemanamen beginnen, gefolgt von einem Doppelpunkt. Für maßgebliche Informationen über URL-Syntax und -Semantik siehe "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396 [42] (das RFC 1738 [4] und RFC 1808 [11] ersetzt). Diese Spezifikation übernimmt die Definitionen von "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path" und "authority" aus dieser Spezifikation.
Das HTTP-Protokoll legt keine a priori Begrenzung für die Länge von URIs fest. Server müssen (MUST) in der Lage sein, URIs aller von ihnen bereitgestellten Ressourcen zu verarbeiten, und sollten (SHOULD) in der Lage sein, URIs unbegrenzter Länge zu verarbeiten, wenn sie GET-basierte Formulare bereitstellen, die solche URIs erzeugen könnten. Ein Server sollte (SHOULD) einen Status 414 (Request-URI Too Long) zurückgeben (siehe Abschnitt 10.4.15), wenn ein URI länger ist, als der Server verarbeiten kann.
Hinweis: Server sollten vorsichtig sein, sich auf URI-Längen über 255 Bytes zu verlassen, da einige ältere Client- oder Proxy-Implementierungen diese Längen möglicherweise nicht richtig unterstützen.
3.2.2 http URL
Das "http"-Schema wird verwendet, um Netzwerkressourcen über das HTTP-Protokoll zu lokalisieren. Dieser Abschnitt definiert die schema-spezifische Syntax und Semantik der http-URL.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Wenn der Port leer oder nicht angegeben ist, wird Port 80 angenommen. Die Semantik ist, dass die identifizierte Ressource sich auf dem Server befindet, der auf diesem Port dieses Hosts auf TCP-Verbindungen hört, und die Request-URI der Ressource ist abs_path (Abschnitt 5.1.2). Die Verwendung von IP-Adressen in URLs sollte (SHOULD) nach Möglichkeit vermieden werden (siehe RFC 1900 [24]). Wenn abs_path nicht in der URL vorhanden ist, muss (MUST) er als "/" angegeben werden, wenn er als Request-URI für eine Ressource verwendet wird (Abschnitt 5.1.2). Wenn ein Proxy einen Hostnamen empfängt, der kein vollqualifizierter Domänenname ist, kann (MAY) er seine Domäne zu dem empfangenen Hostnamen hinzufügen. Wenn ein Proxy einen vollqualifizierten Domänennamen empfängt, darf (MUST NOT) der Proxy den Hostnamen nicht ändern.
3.2.3 URI Comparison (URI-Vergleich)
Beim Vergleichen von zwei URIs, um festzustellen, ob sie übereinstimmen, sollte (SHOULD) ein Client einen case-sensitiven Oktet-für-Oktet-Vergleich des gesamten URI verwenden, mit den folgenden Ausnahmen:
- Ein leerer oder nicht angegebener Port ist äquivalent zum Standardport für diese URI-Referenz;
- Hostnamenvergleiche müssen (MUST) case-insensitive sein;
- Schemanamenvergleiche müssen (MUST) case-insensitive sein;
- Ein leerer abs_path ist äquivalent zu einem abs_path von "/".
Zeichen, die nicht zu den "reserved"- und "unsafe"-Sets gehören (siehe RFC 2396 [42]), sind äquivalent zu ihrer "%HEX HEX"-Kodierung.
Zum Beispiel sind die folgenden drei URIs äquivalent:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 Date/Time Formats (Datums-/Zeitformate)
3.3.1 Full Date (Vollständiges Datum)
HTTP-Anwendungen haben historisch drei verschiedene Datums-/Zeitstempeldarstellungsformate erlaubt:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Das erste Format wird als Internetstandard bevorzugt und repräsentiert eine Teilmenge fester Länge der durch RFC 1123 [8] (eine Aktualisierung von RFC 822 [9]) definierten. Das zweite Format ist weit verbreitet, basiert aber auf dem veralteten RFC 850 [12]-Datumsformat und fehlt ein vierstelliges Jahr. HTTP/1.1-Clients und -Server, die Datumswerte analysieren, müssen (MUST) alle drei Formate akzeptieren (für Kompatibilität mit HTTP/1.0), aber sie müssen (MUST) nur das RFC 1123-Format generieren, um HTTP-date-Werte in Header-Feldern darzustellen. Siehe Abschnitt 19.3 für weitere Informationen.
Hinweis: Empfänger von Datumswerten werden ermutigt, robust zu sein, wenn sie Datumswerte akzeptieren, die möglicherweise von Nicht-HTTP-Anwendungen gesendet wurden, was manchmal beim Abrufen oder Posten von Nachrichten über Proxies/Gateways zu SMTP oder NNTP auftritt.
Alle HTTP-Datums-/Zeitstempel müssen (MUST) ohne Ausnahme in Greenwich Mean Time (GMT) dargestellt werden. Für HTTP ist GMT genau gleich UTC (Coordinated Universal Time). Dies wird in den ersten beiden Formaten durch Einbeziehung von "GMT" als Drei-Buchstaben-Abkürzung für die Zeitzone angezeigt und muss (MUST) beim Lesen des asctime-Formats angenommen werden. HTTP-date ist case-sensitive und darf (MUST NOT) zusätzliche LWS enthalten, außer dem, was explizit als SP in der Grammatik enthalten ist.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Hinweis: Die HTTP-Anforderungen für Datums-/Zeitstempelformate gelten nur für ihre Verwendung im Protokollstrom. Clients und Server müssen diese Formate nicht für Benutzerpräsentation, Anforderungsprotokolle usw. verwenden.
3.3.2 Delta Seconds (Delta-Sekunden)
Einige HTTP-Header-Felder erlauben es, einen Zeitwert als ganze Zahl von Sekunden anzugeben, dargestellt in Dezimalzahl, nach dem Zeitpunkt des Empfangs der Nachricht.
delta-seconds = 1*DIGIT
3.4 Character Sets (Zeichensätze)
HTTP verwendet dieselbe Definition des Begriffs "Zeichensatz" (character set) wie in MIME beschrieben:
Der Begriff "Zeichensatz" wird in diesem Dokument verwendet, um eine Methode zu bezeichnen, die mit einer oder mehreren Tabellen verwendet wird, um eine Sequenz von Oktetten in eine Sequenz von Zeichen zu konvertieren. Beachten Sie, dass keine bedingungslose Konvertierung in die andere Richtung erforderlich ist, da nicht alle Zeichen in einem bestimmten Zeichensatz verfügbar sein müssen und ein Zeichensatz mehrere Oktettsequenzen bereitstellen kann, um ein bestimmtes Zeichen darzustellen. Diese Definition soll verschiedene Zeichenkodierungen ermöglichen, von einfachen Einzeltabellen-Mappings wie US-ASCII bis zu komplexen Tabellenwechselmethoden wie denen, die ISO-2022-Techniken verwenden. Die mit einem MIME-Zeichensatznamen verbundene Definition muss (MUST) jedoch vollständig das Mapping angeben, das von Oktetten zu Zeichen durchzuführen ist. Insbesondere ist die Verwendung externer Profilinformationen zur Bestimmung des genauen Mappings nicht erlaubt.
Hinweis: Diese Verwendung des Begriffs "Zeichensatz" (character set) wird häufiger als "Zeichenkodierung" (character encoding) bezeichnet. Da HTTP und MIME jedoch dasselbe Register teilen, ist es wichtig, dass auch die Begriffe geteilt werden.
HTTP-Zeichensätze werden durch case-insensitive Token identifiziert. Der vollständige Satz von Token wird durch das IANA-Zeichensatzregister [19] definiert.
charset = token
Obwohl HTTP die Verwendung eines beliebigen Tokens als Zeichensatzwert erlaubt, muss (MUST) jedes Token, das einen vordefinierten Wert im IANA-Zeichensatzregister [19] hat, den durch dieses Register definierten Zeichensatz darstellen. Anwendungen sollten (SHOULD) ihre Verwendung von Zeichensätzen auf die durch das IANA-Register definierten beschränken.
Implementierer sollten sich der IETF-Zeichensatzanforderungen [38] [41] bewusst sein.
3.4.1 Missing Charset (Fehlender Zeichensatz)
Einige HTTP/1.0-Software hat fälschlicherweise einen Content-Type-Header ohne Charset-Parameter als "der Empfänger sollte raten" interpretiert. Absender, die dieses Verhalten überwinden möchten, können (MAY) einen Charset-Parameter einschließen, wenn der Zeichensatz ISO-8859-1 ist, und sollten (SHOULD) dies tun, wenn bekannt ist, dass dies den Empfänger nicht verwirrt.
Leider haben einige ältere HTTP/1.0-Clients einen expliziten Charset-Parameter nicht richtig behandelt. HTTP/1.1-Empfänger müssen (MUST) das vom Absender bereitgestellte Charset-Label respektieren; Benutzeragenten, die eine Bestimmung zum "Raten" des Zeichensatzes haben, müssen (MUST) den Zeichensatz aus dem Content-Type-Feld verwenden, anstatt den vom Empfänger abgeleiteten Zeichensatz, selbst wenn der Absender ein HTTP/1.0-Client ist.
3.5 Content Codings (Inhaltskodierungen)
Inhaltskodierungswerte zeigen eine Kodierungstransformation an, die auf eine Entität angewendet wurde oder angewendet werden kann. Inhaltskodierungen werden hauptsächlich verwendet, um die Kompression eines Dokuments zu ermöglichen, ohne die Identifikation seines zugrunde liegenden Medientyps zu verlieren und ohne Informationen zu verlieren. Entitäten werden normalerweise nur in kodierter Form gespeichert, wenn ihre zugrunde liegende Darstellung für die Übertragung kodiert ist.
content-coding = token
Alle Inhaltskodierungswerte sind case-insensitive. HTTP/1.1 verwendet Inhaltskodierungswerte in den Accept-Encoding- und Content-Encoding-Header-Feldern. Obwohl der Wert die auf den Entitätskörper angewendete Inhaltskodierung beschreibt, ist wichtiger, dass er anzeigt, welcher Dekodierungsmechanismus angewendet werden kann, um den durch das Content-Type-Header-Feld referenzierten Medientyp zu erhalten.
Die Internet Assigned Numbers Authority (IANA) dient als Register für Inhaltskodierungswert-Token. Anfänglich enthält das Register die folgenden Token:
gzip Ein Kodierungsformat, das Lempel-Ziv-Kodierung (LZ77) mit einem 32-Bit-CRC verwendet, wie in RFC 1952 [25] beschrieben. Dieses Kodierungsformat wird vom UNIX-gzip-Programm erzeugt. HTTP/1.1-Implementierer werden darauf hingewiesen, dass aus historischen Gründen einige Empfänger "x-gzip" und "gzip" als äquivalent behandeln.
compress Das mit dem Lempel-Ziv-Welch (LZW)-Algorithmus erzeugte Kodierungsformat. Dieses Kodierungsformat wird vom gängigen UNIX-Dateikomprimierungsprogramm "compress" erzeugt. Empfänger sollten aus historischen Gründen "x-compress" und "compress" als äquivalent behandeln.
deflate Die Kombination des in RFC 1950 [31] beschriebenen "zlib"-Formats und des in RFC 1951 [29] beschriebenen "deflate"-Kompressionsmechanismus.
identity Die Standard-(Identitäts-)Kodierung; die Verwendung dieser Inhaltskodierung zeigt nur an, dass keine Kodierung durchgeführt wurde. Diese Inhaltskodierung wird im Accept-Encoding-Header-Feld verwendet und sollte nicht (SHOULD NOT) im Content-Encoding-Header-Feld verwendet werden.
Neue Inhaltskodierungs-Token sollten bei der Internet Assigned Numbers Authority (IANA) registriert werden.
3.6 Transfer Codings (Übertragungskodierungen)
Übertragungskodierungswerte werden verwendet, um eine Kodierungstransformation anzuzeigen, die auf den Entitätskörper angewendet wurde, angewendet werden kann oder möglicherweise angewendet werden muss, um eine "sichere Übertragung" über das Netzwerk zu gewährleisten. Dies unterscheidet sich von einer Inhaltskodierung darin, dass die Übertragungskodierung eine Eigenschaft der Nachricht ist, anstatt der ursprünglichen Entität.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
Parameter nehmen die Form von Attribut/Wert-Paaren an.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
Alle Übertragungskodierungswerte sind case-insensitive. HTTP/1.1 verwendet Übertragungskodierungswerte im TE-Header-Feld (Abschnitt 14.39) und im Transfer-Encoding-Header-Feld (Abschnitt 14.41).
Übertragungskodierungen sind eine neue Funktion von HTTP/1.1. Absender dürfen (MUST NOT) eine Übertragungskodierung auf einen Nachrichtenkörper anwenden, es sei denn, die Nachricht ist als HTTP/1.1 oder höher gekennzeichnet.
3.6.1 Chunked Transfer Coding (Chunked-Übertragungskodierung)
Die Chunked-Kodierung ändert den Nachrichtenkörper, um ihn als eine Reihe von Chunks zu übertragen, von denen jeder seine eigene Größenangabe hat, gefolgt von einem optionalen Trailer, der Entitäts-Header-Felder enthält. Dies ermöglicht es, dynamisch generierte Inhalte zusammen mit den notwendigen Integritätsprüfungsinformationen über die Nachricht zu übertragen.
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
Das chunk-size-Feld ist eine Zeichenfolge von hexadezimalen Ziffern, die die Größe der Chunk-Daten angibt. Die Chunked-Kodierung endet mit einem Chunk der Größe Null, gefolgt vom Trailer, der mit einer Leerzeile endet.
Der Trailer ermöglicht es dem Absender, zusätzliche HTTP-Header-Felder am Ende der Nachricht einzuschließen. Das Trailer-Header-Feld (Abschnitt 14.40) kann verwendet werden, um anzuzeigen, welche Header-Felder im Trailer enthalten sind.
Es ist nicht erlaubt, Nachrichten-Header-Felder im Trailer einzuschließen, es sei denn, sie sind ausdrücklich erlaubt, wie in Abschnitt 7.1 beschrieben.
Ein Server kann (MAY) Chunked-Übertragungskodierung verwenden, wenn die akzeptablen Übertragungskodierungen des Empfängers Chunked-Übertragungskodierung einschließen. Das Vorhandensein des Trailers kann durch Einbeziehung eines Trailer-Header-Felds in der Nachricht angezeigt werden.
Eine Anwendung, die einen gechunkten Nachrichtenkörper empfängt, muss (MUST) Chunk-Erweiterungen ignorieren, die sie nicht versteht, es sei denn, die entsprechende Chunk-Erweiterung ist durch ein Trailer-Header-Feld definiert.
3.7 Media Types (Medientypen)
HTTP verwendet Internet-Medientypen [17] in den Content-Type- (Abschnitt 14.17) und Accept- (Abschnitt 14.1) Header-Feldern, um offene, erweiterbare Datentypisierung und Typverhandlung bezüglich Datentypen bereitzustellen.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Typen, Subtypen und Parameterattributnamen sind case-insensitive. Parameterwerte können je nach Semantik des Parameternamens case-sensitive oder case-insensitive sein. Lineares Leerzeichen (LWS) darf (MUST NOT) zwischen Typ und Subtyp oder zwischen einem Attribut und seinem Wert verwendet werden. Benutzeragenten sollten (SHOULD) das durch Medientyp-Parameter identifizierte Charset-Label (Abschnitt 3.4) respektieren.
Das Vorhandensein eines Medientypwerts impliziert nicht, dass ein Entitätskörper in der HTTP-Nachricht vorhanden sein muss. Für einige Methoden oder Antworten bestimmter Antwortcodes kann eine Antwortnachricht ein Content-Type-Header-Feld enthalten, auch wenn die Nachricht keinen Entitätskörper enthält. Solche Antwortnachrichten beginnen mit einer Leerzeile, die die Header-Felder beendet, anstatt mit einem Entitätskörper.
3.7.1 Canonicalization and Text Defaults (Kanonisierung und Text-Standards)
Als Standard registrierte Internet-Medientypen mit dem Haupttyp "text" übernehmen dieselben Regeln wie in MIME. Dies bedeutet, dass, wenn der "charset"-Parameter nicht im Content-Type-Header-Feld eines Medientyps mit dem Haupttyp "text" enthalten ist, der Empfänger ihn (SHOULD) als Zeichensatz "ISO-8859-1" behandeln sollte (siehe Abschnitt 3.4.1). Die Daten eines "text"-Bytestroms in HTTP werden in "kanonischer Form" (canonical form) gesendet; das heißt, HTTP führt keine Übersetzung von CRLF-Zeilenendesequenzen durch.
3.7.2 Multipart Types (Multipart-Typen)
MIME bietet eine Reihe von Multipart-Typen - die eine oder mehrere Entitäten in einem einzelnen Nachrichtenkörper kapseln. Alle Multipart-Typen teilen eine gemeinsame Syntax, wie in Abschnitt 5.1 von MIME [7] definiert, und müssen (MUST) einen Boundary-Parameter als Teil des Medientypwerts enthalten. Der Nachrichtenkörper selbst ist ein Protokollelement und muss (MUST) daher CRLF als Zeilentrennzeichen zwischen zwei Körperteilen verwenden. Im Gegensatz zu MIME muss (MUST) das Ende eines Multipart-Körpers in HTTP mit einem abschließenden Boundary-Trennzeichen markiert sein.
In HTTP sollten (SHOULD) dieselben Semantiken für den Content-Location-Header für Multipart-Typen wie in MIME befolgt werden; in HTTP wird jedoch jeder Körperteil mit einem Content-Location-Header als eine unabhängige Identität behandelt, selbst wenn er mit dem externen Content-Location seiner enthaltenden Nachricht übereinstimmt.
Im Allgemeinen behandelt HTTP Multipart-Körperteile als separate Ressourcen, jede mit ihrem eigenen URI. Dies ermöglicht das parallele oder sequentielle Senden mehrerer Ressourcen in einer Nachricht und unterstützt 206 (Partial Content)-Antworten.
3.8 Product Tokens (Produkt-Token)
Produkt-Token werden verwendet, um kommunizierenden Anwendungen zu ermöglichen, sich durch Softwarenamen und -version zu identifizieren. Die meisten Felder, die Produkt-Token verwenden, erlauben auch das Auflisten von Unterprodukten, die einen bedeutenden Teil der Anwendung bilden, getrennt durch Leerzeichen. Nach Konvention werden Produkte in absteigender Reihenfolge ihrer Bedeutung für die Anwendung aufgelistet.
product = token ["/" product-version]
product-version = token
Beispiele:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Produkt-Token sollten (SHOULD) kurz und unbedeutend sein. Sie dürfen (MUST NOT) für Werbung oder andere nicht wesentliche Informationen verwendet werden. Obwohl beliebige Token-Zeichen in einer Produktversion erscheinen können, sollte (SHOULD) dieses Token nur für eine Version des Produkts verwendet werden (d.h. aufeinanderfolgende Versionen sollten sich nur im Wert des Produktversions-Tokens unterscheiden).
3.9 Quality Values (Qualitätswerte)
Die HTTP-Inhaltsverhandlung (Abschnitt 12) verwendet kurze "Gleitkomma"-Zahlen, um die relative Wichtigkeit ("Gewicht") verschiedener verhandelbarer Parameter anzuzeigen. Gewichte werden auf reelle Werte zwischen 0 und 1 normalisiert, wobei 0 der Minimalwert und 1 der Maximalwert ist. HTTP/1.1-Anwendungen dürfen (MUST NOT) Qualitätswerte mit mehr als drei Dezimalstellen generieren. Die Benutzerkonfiguration dieser Werte sollte ähnlich beschränkt werden.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
Das Konzept des "Qualitätswerts" gilt für die Auswahl von jedem Inhalt (siehe Abschnitt 14.1), Zeichensatz (Abschnitt 14.2), Inhaltskodierung (Abschnitt 14.3), Sprache (Abschnitt 14.4) oder Übertragungskodierung (Abschnitt 14.39). Zur Kürze bezieht sich jedoch der in diesem Abschnitt verwendete Begriff "Qualitätswert" auf eine dieser mit diesem Qualitätswert verbundenen Eigenschaften.
3.10 Language Tags (Sprach-Tags)
Ein Sprach-Tag identifiziert eine natürliche Sprache wie Englisch oder Französisch, bestehend aus einem oder mehreren Teilen: einem primären Sprach-Tag und möglicherweise einer Reihe von Sub-Tags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Leerzeichen sind innerhalb des Tags nicht erlaubt, und alle Tags sind case-insensitive. Der Namensraum der Tags wird von IANA verwaltet. Beispiel-Tags umfassen:
en, en-US, en-cockney, i-cherokee, x-pig-latin
wobei jedes Zwei-Zeichen-Primär-Tag eine ISO-639-Sprachabkürzung [34] ist und jedes Zwei-Zeichen-Anfangs-Sub-Tag ein ISO-3166-Ländercode [35] ist. (Die letzte Offline-Version von ISO 639 zum Zeitpunkt der Erstellung dieses Dokuments ist [35], aber man sollte erwarten, dass dieser Standard sich im Laufe der Zeit weiterentwickelt.)
3.11 Entity Tags (Entitäts-Tags)
Entitäts-Tags werden für den Vergleich zwischen mehreren Darstellungen derselben angeforderten Ressource verwendet. Entitäts-Tags bestehen aus einer opaken Zeichenfolge in Anführungszeichen, möglicherweise mit einem Schwäche-Indikator-Präfix (siehe Abschnitt 13.3.3).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
Ein "starkes Entitäts-Tag" (strong entity tag) kann jederzeit verwendet werden, wenn ein Entitäts-Tag verwendet wird, unabhängig davon, wie sich der Entitätswert ändert. Ein "schwaches Entitäts-Tag" (weak entity tag) wird nur für schwache Vergleiche verwendet, wenn die semantische Äquivalenz des Entitätswerts, anstatt der Byte-Äquivalenz, ausreichend ist.
Ein schwaches Entitäts-Tag kann nur für schwache Vergleiche verwendet werden. Ein Entitäts-Tag ohne Schwäche-Indikator-Präfix ist ein starkes Entitäts-Tag.
Entitäts-Tags müssen (MUST) für zwei Entitäten einer bestimmten Ressource eindeutig sein, es sei denn, die Semantiken dieser Entitäten sind äquivalent.
3.12 Range Units (Bereichseinheiten)
HTTP/1.1 ermöglicht es einem Client, zu verlangen, dass nur ein Teil (Bereich) der Antwortentität übertragen wird. HTTP/1.1 verwendet Bereichseinheiten in den Range- (Abschnitt 14.35), Content-Range- (Abschnitt 14.16) und Accept-Ranges- (Abschnitt 14.5) Header-Feldern. Eine Entität kann in Unter-Bereiche gemäß verschiedenen strukturellen Einheiten zerlegt werden.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
Die einzige Bereichseinheit in HTTP/1.1 ist "bytes". HTTP/1.1-Implementierungen können (MAY) Spezifikationen von Bereichseinheiten ignorieren, die sie nicht verstehen.
HTTP/1.1 wurde für die "bytes"-Bereichseinheit registriert. Der Anhang enthält die Registrierung einiger anderer Bereichseinheiten.