16. Extending HTTP (HTTP-Erweiterung)

HTTP definiert eine Reihe generischer Erweiterungspunkte, die verwendet werden können, um Funktionen in das Protokoll einzuführen, ohne eine neue Version einzuführen, einschließlich Methoden, Statuscodes, Feldnamen und weiteren Erweiterungspunkten innerhalb definierter Felder, wie Authentifizierungsschemas und Cache-Direktiven (siehe Cache-Control-Erweiterungen in Abschnitt 5.2.3 von [CACHING]). Da die Semantik von HTTP nicht versioniert ist, sind diese Erweiterungspunkte persistent; die verwendete Protokollversion beeinflusst ihre Semantik nicht.

Versionsunabhängige Erweiterungen sollten nicht von der spezifischen Version des verwendeten Protokolls abhängen oder mit ihr interagieren. Wenn dies unvermeidlich ist, muss sorgfältig überlegt werden, wie die Erweiterung über Versionen hinweg interoperieren kann.

Darüber hinaus können spezifische Versionen von HTTP ihre eigenen Erweiterungspunkte haben, wie z.B. Transfer-Codierungen in HTTP/1.1 (Abschnitt 6.1 von [HTTP/1.1]) und HTTP/2-SETTINGS oder Frame-Typen ([HTTP/2]). Diese Erweiterungspunkte sind spezifisch für die Protokollversion, in der sie vorkommen.

Versionsspezifische Erweiterungen können die Semantik eines versionsunabhängigen Mechanismus oder Erweiterungspunkts (wie eine Methode oder ein Header-Feld) nicht überschreiben oder modifizieren, ohne explizit von diesem Protokollelement erlaubt zu werden. Zum Beispiel erlaubt die CONNECT-Methode (Abschnitt 9.3.6) dies.

Diese Richtlinien stellen sicher, dass das Protokoll korrekt und vorhersehbar funktioniert, auch wenn Teile des Pfads unterschiedliche Versionen von HTTP implementieren.

16.1. Method Extensibility (Methodenerweiterbarkeit)

16.1.1. Method Registry (Methodenregister)

Das "Hypertext Transfer Protocol (HTTP) Method Registry", das von der IANA unter https://www.iana.org/assignments/http-methods gepflegt wird, registriert Methodennamen.

HTTP-Methodenregistrierungen MÜSSEN die folgenden Felder enthalten:

• Method Name (Methodenname) (siehe Abschnitt 9)
• Safe ("yes" oder "no", siehe Abschnitt 9.2.1)
• Idempotent ("yes" oder "no", siehe Abschnitt 9.2.2)
• Pointer to specification text (Verweis auf Spezifikationstext)

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe [RFC8126], Abschnitt 4.8).

16.1.2. Considerations for New Methods (Überlegungen für neue Methoden)

Standardisierte Methoden sind generisch; das heißt, sie sind potenziell auf jede Ressource anwendbar, nicht nur auf einen bestimmten Medientyp, eine Art von Ressource oder eine Anwendung. Daher ist es vorzuziehen, dass neue Methoden in einem Dokument registriert werden, das nicht spezifisch für eine einzelne Anwendung oder ein Datenformat ist, da orthogonale Technologien orthogonale Spezifikationen verdienen.

Da das Parsen von Nachrichten (Abschnitt 6) unabhängig von der Methodensemantik sein muss (abgesehen von Antworten auf HEAD), können Definitionen neuer Methoden den Parsing-Algorithmus nicht ändern oder das Vorhandensein von Inhalt in der Anfrage- oder Antwortnachricht verbieten. Definitionen neuer Methoden können spezifizieren, dass nur Inhalt mit Länge Null erlaubt ist, indem ein Content-Length-Header-Feld mit einem Wert von "0" erforderlich ist.

Ebenso können neue Methoden nicht die speziellen host:port- und Asterisk-Formen des Anforderungsziels verwenden, die für CONNECT bzw. OPTIONS erlaubt sind (Abschnitt 7.1). Ein vollständiger URI in absoluter Form ist für den Ziel-URI erforderlich, was bedeutet, dass entweder das Anforderungsziel in absoluter Form gesendet werden muss oder der Ziel-URI aus dem Anforderungskontext auf die gleiche Weise rekonstruiert wird wie für andere Methoden.

Eine neue Methodendefinition muss angeben, ob sie sicher (Abschnitt 9.2.1), idempotent (Abschnitt 9.2.2), cachebar (Abschnitt 9.2.3) ist, welche Semantik mit dem Anforderungsinhalt verbunden sein soll (falls vorhanden) und welche Verfeinerungen die Methode an der Header-Feld- oder Statuscode-Semantik vornimmt. Wenn die neue Methode cachebar ist, sollte ihre Definition beschreiben, wie und unter welchen Bedingungen ein Cache eine Antwort speichern und verwenden kann, um eine nachfolgende Anfrage zu erfüllen. Die neue Methode sollte beschreiben, ob sie bedingt gemacht werden kann (Abschnitt 13.1) und, wenn ja, wie ein Server antwortet, wenn die Bedingung falsch ist. Ebenso sollte dokumentiert werden, wenn die neue Methode eine gewisse Verwendung für Teilantwort-Semantik (Abschnitt 14.2) haben könnte.

Hinweis: Vermeiden Sie die Definition von Methodennamen, die mit "M-" beginnen, da dieses Präfix als mit der Semantik interpretiert werden könnte, die ihm durch [RFC2774] zugewiesen wurde.

16.2. Status Code Extensibility (Statuscode-Erweiterbarkeit)

16.2.1. Status Code Registry (Statuscode-Register)

Das "Hypertext Transfer Protocol (HTTP) Status Code Registry", das von der IANA unter https://www.iana.org/assignments/http-status-codes gepflegt wird, registriert Statuscode-Nummern.

Eine Registrierung MUSS die folgenden Felder enthalten:

• Status Code (Statuscode) (3 Ziffern)
• Short Description (Kurzbeschreibung)
• Pointer to specification text (Verweis auf Spezifikationstext)

Werte, die zum HTTP-Statuscode-Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe [RFC8126], Abschnitt 4.8).

16.2.2. Considerations for New Status Codes (Überlegungen für neue Statuscodes)

Wenn es notwendig ist, Semantik für eine Antwort auszudrücken, die nicht durch aktuelle Statuscodes definiert ist, kann ein neuer Statuscode registriert werden. Statuscodes sind generisch; sie sind potenziell auf jede Ressource anwendbar, nicht nur auf einen bestimmten Medientyp, eine Art von Ressource oder eine HTTP-Anwendung. Daher ist es vorzuziehen, dass neue Statuscodes in einem Dokument registriert werden, das nicht spezifisch für eine einzelne Anwendung ist.

Neue Statuscodes müssen unter eine der in Abschnitt 15 definierten Kategorien fallen. Um vorhandenen Parsern die Verarbeitung der Antwortnachricht zu ermöglichen, können neue Statuscodes Inhalt nicht verbieten, obwohl sie Inhalt mit Länge Null vorschreiben können.

Vorschläge für neue Statuscodes, die noch nicht weit verbreitet sind, sollten vermeiden, eine bestimmte Nummer für den Code zuzuweisen, bis ein klarer Konsens besteht, dass er registriert wird; stattdessen können frühe Entwürfe eine Notation wie "4NN" oder "3N0" .. "3N9" verwenden, um die Klasse des/der vorgeschlagenen Statuscode(s) anzugeben, ohne vorzeitig eine Nummer zu verbrauchen.

Die Definition eines neuen Statuscodes sollte die Anforderungsbedingungen erläutern, die eine Antwort verursachen würden, die diesen Statuscode enthält (z.B. Kombinationen von Anforderungs-Header-Feldern und/oder Methode(n)), zusammen mit allen Abhängigkeiten von Antwort-Header-Feldern (z.B. welche Felder erforderlich sind, welche Felder die Semantik ändern können und welche Feldsemantik weiter verfeinert wird, wenn sie mit dem neuen Statuscode verwendet wird).

Standardmäßig gilt ein Statuscode nur für die Anforderung, die der Antwort entspricht, in der er auftritt. Wenn ein Statuscode einen größeren Anwendungsbereich hat -- zum Beispiel alle Anforderungen an die betreffende Ressource oder alle Anforderungen an einen Server -- MUSS dies explizit angegeben werden. Dabei sollte beachtet werden, dass nicht alle Clients einen größeren Bereich konsistent anwenden werden, da sie den neuen Statuscode möglicherweise nicht verstehen.

Die Definition eines neuen finalen Statuscodes sollte angeben, ob er heuristisch cachebar ist oder nicht. Beachten Sie, dass jede Antwort mit einem finalen Statuscode gecacht werden kann, wenn sie explizite Frischeinformationen enthält. Ein als heuristisch cachebar definierter Statuscode darf ohne explizite Frischeinformationen gecacht werden. Ebenso kann die Definition eines Statuscodes Einschränkungen für das Cache-Verhalten auferlegen, wenn die must-understand-Cache-Direktive verwendet wird. Siehe [CACHING] für weitere Informationen.

Schließlich sollte die Definition eines neuen Statuscodes angeben, ob der Inhalt eine implizite Verbindung mit einer identifizierten Ressource hat (Abschnitt 6.4.2).

16.3. Field Extensibility (Felderweiterbarkeit)

Der am weitesten verbreitete Erweiterungspunkt von HTTP ist die Definition neuer Header- und Trailer-Felder.

Neue Felder können so definiert werden, dass sie, wenn sie von einem Empfänger verstanden werden, die Interpretation zuvor definierter Felder überschreiben oder verbessern, Vorbedingungen für die Anforderungsbewertung definieren oder die Bedeutung von Antworten verfeinern.

Die Definition eines Felds garantiert jedoch nicht dessen Bereitstellung oder Erkennung durch Empfänger. Die meisten Felder sind so konzipiert, dass ein Empfänger jedes nicht erkannte Feld sicher ignorieren (aber nachgeschaltet weiterleiten) kann. In anderen Fällen kann die Fähigkeit des Absenders, ein bestimmtes Feld zu verstehen, durch seine vorherige Kommunikation angezeigt werden, möglicherweise in der Protokollversion oder den Feldern, die er in früheren Nachrichten gesendet hat, oder seiner Verwendung eines bestimmten Medientyps. Ebenso könnte eine direkte Inspektion der Unterstützung durch eine OPTIONS-Anfrage oder durch Interaktion mit einem definierten well-known URI [RFC8615] möglich sein, wenn eine solche Inspektion zusammen mit dem eingeführten Feld definiert ist.

16.3.1. Field Name Registry (Feldnamen-Register)

Das "Hypertext Transfer Protocol (HTTP) Field Name Registry" definiert den Namensraum für HTTP-Feldnamen.

Jede Partei kann die Registrierung eines HTTP-Felds beantragen. Siehe Abschnitt 16.3.2 für Überlegungen, die bei der Erstellung eines neuen HTTP-Felds zu berücksichtigen sind.

Das "Hypertext Transfer Protocol (HTTP) Field Name Registry" befindet sich unter https://www.iana.org/assignments/http-fields/. Registrierungsanträge können durch Befolgung der dort aufgeführten Anweisungen oder durch Senden einer E-Mail an die Mailingliste "[email protected]" gestellt werden.

Feldnamen werden auf Anraten eines designierten Experten (ernannt vom IESG oder dessen Delegiertem) registriert. Felder mit dem Status 'permanent' sind Specification Required ([RFC8126], Abschnitt 4.6).

Registrierungsanträge bestehen aus den folgenden Informationen:

Field name (Feldname): Der beantragte Feldname. Er MUSS der in Abschnitt 5.1 definierten field-name-Syntax entsprechen und SOLLTE auf Buchstaben, Ziffern und Bindestrich-Zeichen ('-') beschränkt sein, wobei das erste Zeichen ein Buchstabe sein sollte.

Status: "permanent", "provisional", "deprecated" oder "obsoleted".

Specification document(s) (Spezifikationsdokument(e)): Eine Referenz auf das Dokument, das das Feld spezifiziert, vorzugsweise einschließlich eines URI, der verwendet werden kann, um eine Kopie des Dokuments abzurufen. Eine Angabe der relevanten Abschnitte kann ebenfalls enthalten sein, ist aber nicht erforderlich.

Und optional:

Comments (Kommentare): Zusätzliche Informationen, wie Informationen über reservierte Einträge.

Der/Die Experte(n) können zusätzliche Felder definieren, die im Register gesammelt werden sollen, in Absprache mit der Community.

Durch Standards definierte Namen haben den Status "permanent". Andere Namen können auch als permanent registriert werden, wenn der/die Experte(n) feststellt/feststellen, dass sie verwendet werden und, in Absprache mit der Community, der/die Experte(n) sie für angemessen hält/halten. Andere Namen SOLLTEN als "provisional" registriert werden.

Provisorische Einträge können vom/von den Experten entfernt werden, wenn, in Absprache mit der Community, der/die Experte(n) feststellt/feststellen, dass sie nicht verwendet werden. Der/Die Experte(n) kann/können den Status eines provisorischen Eintrags jederzeit auf permanent ändern.

Beachten Sie, dass Namen von Dritten (einschließlich des/der Experten) registriert werden können, wenn der/die Experte(n) feststellt/feststellen, dass ein nicht registrierter Name weit verbreitet ist und wahrscheinlich nicht rechtzeitig registriert wird.

16.3.2. Considerations for New Fields (Überlegungen für neue Felder)

HTTP-Header- und Trailer-Felder sind ein weit verbreiteter Erweiterungspunkt für das Protokoll. Obwohl sie ad hoc verwendet werden können, müssen Felder, die für eine breitere Verwendung vorgesehen sind, sorgfältig dokumentiert werden, um Interoperabilität zu gewährleisten.

Insbesondere wird Autoren von Spezifikationen, die neue Felder definieren, empfohlen, die folgenden Aspekte zu berücksichtigen und gegebenenfalls zu dokumentieren:

• Unter welchen Bedingungen das Feld verwendet werden kann; z.B. nur in Antworten oder Anfragen, in allen Nachrichten, nur bei Antworten auf eine bestimmte Anforderungsmethode usw.

• Ob die Feldsemantik durch ihren Kontext weiter verfeinert wird, wie z.B. ihre Verwendung mit bestimmten Anforderungsmethoden oder Statuscodes.

• Der Anwendungsbereich für die übermittelten Informationen. Standardmäßig gelten Felder nur für die Nachricht, mit der sie verbunden sind, aber einige Antwortfelder sind so konzipiert, dass sie für alle Darstellungen einer Ressource, die Ressource selbst oder einen noch größeren Bereich gelten. Spezifikationen, die den Bereich eines Antwortfelds erweitern, müssen Fragen wie Content-Negotiation, den Zeitraum der Anwendbarkeit und (in einigen Fällen) Multi-Tenant-Server-Bereitstellungen sorgfältig berücksichtigen.

• Unter welchen Bedingungen Vermittler den Wert des Felds einfügen, löschen oder ändern dürfen.

• Ob das Feld in Trailern zulässig ist; standardmäßig wird es das nicht sein (siehe Abschnitt 6.5.1).

• Ob es angemessen oder sogar erforderlich ist, den Feldnamen im Connection-Header-Feld aufzulisten (d.h., wenn das Feld hop-by-hop ist; siehe Abschnitt 7.6.1).

• Ob das Feld zusätzliche Sicherheitsüberlegungen einführt, wie z.B. die Offenlegung datenschutzbezogener Daten.

Anforderungs-Header-Felder, die ein anderes Verhalten als das Standardverhalten zulassen möchten, haben zusätzliche Überlegungen zu dokumentieren:

• Ob es angemessen ist, den Feldnamen im Vary-Antwort-Header-Feld aufzulisten (z.B. wenn der Content-Auswahlalgorithmus des Origin-Servers das Anforderungs-Header-Feld verwendet; siehe Abschnitt 12.5.5).

• Ob das Feld dazu bestimmt ist, von einem Server gespeichert zu werden, wenn es in einer PUT-Anfrage empfangen wird (siehe Abschnitt 9.3.4).

• Ob das Feld aus Sicherheitsgründen entfernt werden sollte, wenn eine Anfrage automatisch umgeleitet wird (siehe Abschnitt 15.4).

16.3.2.1. Considerations for New Field Names (Überlegungen für neue Feldnamen)

Autoren von Spezifikationen, die neue Felder definieren, wird empfohlen, einen kurzen, aber beschreibenden Feldnamen zu wählen. Kurze Namen vermeiden unnötige Datenübertragung; beschreibende Namen vermeiden Verwirrung und "Squatting" auf Namen, die breitere Verwendungen haben könnten.

Zu diesem Zweck werden Felder mit begrenzter Verwendung (wie ein Header, der auf eine einzelne Anwendung oder einen Anwendungsfall beschränkt ist) ermutigt, einen Namen zu verwenden, der diese Verwendung (oder eine Abkürzung) als Präfix enthält; zum Beispiel, wenn die Foo-Anwendung ein Description-Feld benötigt, könnte sie "Foo-Desc" verwenden; "Description" ist zu generisch, und "Foo-Description" ist unnötig lang.

Während die field-name-Syntax so definiert ist, dass sie jedes Token-Zeichen zulässt, setzen einige Implementierungen in der Praxis Grenzen für die Zeichen, die sie in Feldnamen akzeptieren. Um interoperabel zu sein, SOLLTEN neue Feldnamen sich auf alphanumerische Zeichen, "-" und "." beschränken und SOLLTEN mit einem Buchstaben beginnen. Zum Beispiel kann das Unterstrich-Zeichen ("_") problematisch sein, wenn es durch Nicht-HTTP-Gateway-Schnittstellen geleitet wird (siehe Abschnitt 17.10).

Feldnamen sollten nicht mit "X-" beginnen; siehe [BCP178] für weitere Informationen.

Andere Präfixe werden manchmal in HTTP-Feldnamen verwendet; zum Beispiel wird "Accept-" in vielen Content-Negotiation-Headern verwendet, und "Content-" wird wie in Abschnitt 6.4 erklärt verwendet. Diese Präfixe sind nur eine Hilfe zum Erkennen des Zwecks eines Felds und lösen keine automatische Verarbeitung aus.

16.3.2.2. Considerations for New Field Values (Überlegungen für neue Feldwerte)

Eine Hauptaufgabe bei der Definition eines neuen HTTP-Felds ist die Spezifikation der Feldwert-Syntax: was Absender generieren sollten und wie Empfänger Semantik aus dem Empfangenen ableiten sollten.

Autoren werden ermutigt (aber nicht verpflichtet), entweder die ABNF-Regeln in dieser Spezifikation oder die in [RFC8941] zu verwenden, um die Syntax neuer Feldwerte zu definieren.

Autoren wird empfohlen, sorgfältig zu überlegen, wie die Kombination mehrerer Feldzeilen sie beeinflussen wird (siehe Abschnitt 5.3). Da Absender fälschlicherweise mehrere Werte senden können und sowohl Vermittler als auch HTTP-Bibliotheken die Kombination automatisch durchführen können, gilt dies für alle Feldwerte -- auch wenn nur ein einzelner Wert erwartet wird.

Daher wird Autoren empfohlen, Werte zu begrenzen oder zu codieren, die Kommas enthalten (z.B. mit der quoted-string-Regel von Abschnitt 5.6.4, dem String-Datentyp von [RFC8941] oder einer feldspezifischen Codierung). Dies stellt sicher, dass Kommas innerhalb von Felddaten nicht mit den Kommas verwechselt werden, die einen Listenwert begrenzen.

Zum Beispiel erlaubt der Content-Type-Feldwert Kommas nur innerhalb von in Anführungszeichen gesetzten Zeichenfolgen, die zuverlässig analysiert werden können, auch wenn mehrere Werte vorhanden sind. Der Location-Feldwert liefert ein Gegenbeispiel, das nicht nachgeahmt werden sollte: Da URIs Kommas enthalten können, ist es nicht möglich, zuverlässig zwischen einem einzelnen Wert, der ein Komma enthält, und zwei Werten zu unterscheiden.

Autoren von Feldern mit Singleton-Werten (siehe Abschnitt 5.5) wird außerdem empfohlen zu dokumentieren, wie eine Nachricht behandelt werden soll, die mehrere Mitglieder enthält (ein vernünftiger Standardwert wäre, das Feld zu ignorieren, aber dies ist möglicherweise nicht immer die richtige Wahl).

16.4. Authentication Scheme Extensibility (Authentifizierungsschema-Erweiterbarkeit)

16.4.1. Authentication Scheme Registry (Authentifizierungsschema-Register)

Das "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" definiert den Namensraum für die Authentifizierungsschemata in Challenges und Credentials. Es wird unter https://www.iana.org/assignments/http-authschemes gepflegt.

Registrierungen MÜSSEN die folgenden Felder enthalten:

• Authentication Scheme Name (Authentifizierungsschema-Name)
• Pointer to specification text (Verweis auf Spezifikationstext)
• Notes (Anmerkungen) (optional)

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe [RFC8126], Abschnitt 4.8).

16.4.2. Considerations for New Authentication Schemes (Überlegungen für neue Authentifizierungsschemata)

Es gibt bestimmte Aspekte des HTTP-Authentifizierungs-Frameworks, die Einschränkungen dafür auferlegen, wie neue Authentifizierungsschemata funktionieren können:

• HTTP-Authentifizierung wird als zustandslos angenommen: Alle Informationen, die zur Authentifizierung einer Anfrage erforderlich sind, MÜSSEN in der Anfrage bereitgestellt werden, anstatt davon abhängig zu sein, dass sich der Server an vorherige Anfragen erinnert. Authentifizierung, die auf der zugrunde liegenden Verbindung basiert oder an sie gebunden ist, liegt außerhalb des Anwendungsbereichs dieser Spezifikation und ist grundsätzlich fehlerhaft, es sei denn, es werden Maßnahmen ergriffen, um sicherzustellen, dass die Verbindung von keiner anderen Partei als dem authentifizierten Benutzer verwendet werden kann (siehe Abschnitt 3.3).

• Der Authentifizierungsparameter "realm" ist für die Definition von Schutzbereichen wie in Abschnitt 11.5 beschrieben reserviert. Neue Schemata DÜRFEN ihn NICHT auf eine Weise verwenden, die mit dieser Definition inkompatibel ist.

• Die "token68"-Notation wurde zur Kompatibilität mit bestehenden Authentifizierungsschemata eingeführt und kann nur einmal pro Challenge oder Credential verwendet werden. Daher sollten neue Schemata stattdessen die auth-param-Syntax verwenden, da sonst zukünftige Erweiterungen unmöglich sein werden.

• Das Parsen von Challenges und Credentials ist durch diese Spezifikation definiert und kann nicht durch neue Authentifizierungsschemata geändert werden. Wenn die auth-param-Syntax verwendet wird, sollten alle Parameter sowohl Token- als auch Quoted-String-Syntax unterstützen, und syntaktische Einschränkungen sollten nach dem Parsen (d.h. nach der Verarbeitung von Quoted-Strings) auf den Feldwert definiert werden. Dies ist notwendig, damit Empfänger einen generischen Parser verwenden können, der für alle Authentifizierungsschemata gilt.

  Hinweis: Die Tatsache, dass die Wertsyntax für den "realm"-Parameter auf Quoted-Strings beschränkt ist, war eine schlechte Designentscheidung, die für neue Parameter nicht wiederholt werden sollte.

• Die Definition neuer Schemata sollte die Behandlung unbekannter Erweiterungsparameter definieren. Im Allgemeinen ist eine "must-ignore"-Regel einer "must-understand"-Regel vorzuziehen, da es sonst schwierig sein wird, neue Parameter in Gegenwart von Legacy-Empfängern einzuführen. Darüber hinaus ist es gut, die Richtlinie für die Definition neuer Parameter zu beschreiben (z.B. "Spezifikation aktualisieren" oder "dieses Register verwenden").

• Authentifizierungsschemata müssen dokumentieren, ob sie für die Origin-Server-Authentifizierung (d.h. unter Verwendung von WWW-Authenticate) und/oder Proxy-Authentifizierung (d.h. unter Verwendung von Proxy-Authenticate) verwendbar sind.

• Die in einem Authorization-Header-Feld übertragenen Credentials sind spezifisch für den User-Agent und haben daher die gleiche Wirkung auf HTTP-Caches wie die "private"-Cache-Antwort-Direktive ([CACHING], Abschnitt 5.2.2.7) im Bereich der Anfrage, in der sie erscheinen.

  Daher müssen neue Authentifizierungsschemata, die sich dafür entscheiden, keine Credentials im Authorization-Header-Feld zu übertragen (z.B. unter Verwendung eines neu definierten Header-Felds), das Caching explizit verbieten, indem sie die Verwendung von Cache-Antwort-Direktiven (z.B. "private") vorschreiben.

• Schemata, die Authentication-Info, Proxy-Authentication-Info oder ein anderes authentifizierungsbezogenes Antwort-Header-Feld verwenden, müssen die zugehörigen Sicherheitsüberlegungen berücksichtigen und dokumentieren (siehe Abschnitt 17.16.4).

16.5. Range Unit Extensibility (Bereichseinheit-Erweiterbarkeit)

16.5.1. Range Unit Registry (Bereichseinheit-Register)

Das "HTTP Range Unit Registry" definiert den Namensraum für die Namen von Bereichseinheiten und verweist auf ihre entsprechenden Spezifikationen. Es wird unter https://www.iana.org/assignments/http-parameters gepflegt.

Die Registrierung einer HTTP-Bereichseinheit MUSS die folgenden Felder enthalten:

• Name
• Description (Beschreibung)
• Pointer to specification text (Verweis auf Spezifikationstext)

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe [RFC8126], Abschnitt 4.8).

16.5.2. Considerations for New Range Units (Überlegungen für neue Bereichseinheiten)

Andere Bereichseinheiten, wie formatspezifische Grenzen wie Seiten, Abschnitte, Datensätze, Zeilen oder Zeit, sind potenziell in HTTP für anwendungsspezifische Zwecke verwendbar, werden aber in der Praxis nicht häufig verwendet. Implementierer alternativer Bereichseinheiten sollten überlegen, wie sie mit Content-Codierungen und Allzweck-Vermittlern funktionieren würden.

16.6. Content Coding Extensibility (Content-Coding-Erweiterbarkeit)

16.6.1. Content Coding Registry (Content-Coding-Register)

Das "HTTP Content Coding Registry", das von der IANA unter https://www.iana.org/assignments/http-parameters/ gepflegt wird, registriert content-coding-Namen.

Content-Coding-Registrierungen MÜSSEN die folgenden Felder enthalten:

• Name
• Description (Beschreibung)
• Pointer to specification text (Verweis auf Spezifikationstext)

Namen von Content-Codierungen DÜRFEN NICHT mit Namen von Transfer-Codierungen überlappen (gemäß dem "HTTP Transfer Coding Registry" unter https://www.iana.org/assignments/http-parameters/), es sei denn, die Codierungstransformation ist identisch (wie bei den in Abschnitt 8.4.1 definierten Kompressions-Codierungen).

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern eine IETF-Überprüfung (siehe Abschnitt 4.8 von [RFC8126]) und MÜSSEN dem in Abschnitt 8.4.1 definierten Zweck der Content-Codierung entsprechen.

16.6.2. Considerations for New Content Codings (Überlegungen für neue Content-Codierungen)

Neue Content-Codierungen sollten nach Möglichkeit selbstbeschreibend sein, mit optionalen Parametern, die im Codierungsformat selbst auffindbar sind, anstatt sich auf externe Metadaten zu verlassen, die während der Übertragung verloren gehen könnten.

16.7. Upgrade Token Registry (Upgrade-Token-Register)

Das "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" definiert den Namensraum für protocol-name-Tokens, die verwendet werden, um Protokolle im Upgrade-Header-Feld zu identifizieren. Das Register wird unter https://www.iana.org/assignments/http-upgrade-tokens gepflegt.

Jeder registrierte Protokollname ist mit Kontaktinformationen und einem optionalen Satz von Spezifikationen verbunden, die detailliert beschreiben, wie die Verbindung nach dem Upgrade verarbeitet wird.

Registrierungen erfolgen auf "First Come First Served"-Basis (siehe Abschnitt 4.4 von [RFC8126]) und unterliegen den folgenden Regeln:

1. Ein protocol-name-Token bleibt, einmal registriert, für immer registriert.

2. Ein protocol-name-Token ist case-insensitive und wird mit der bevorzugten Schreibweise registriert, die von Absendern generiert werden soll.

3. Die Registrierung MUSS eine verantwortliche Partei für die Registrierung benennen.

4. Die Registrierung MUSS eine Kontaktstelle benennen.

5. Die Registrierung KANN einen Satz von Spezifikationen benennen, die mit diesem Token verbunden sind. Solche Spezifikationen müssen nicht öffentlich verfügbar sein.

6. Die Registrierung SOLLTE einen Satz erwarteter "protocol-version"-Tokens benennen, die zum Zeitpunkt der Registrierung mit diesem Token verbunden sind.

7. Die verantwortliche Partei KANN die Registrierung jederzeit ändern. Die IANA wird eine Aufzeichnung aller solchen Änderungen führen und sie auf Anfrage zur Verfügung stellen.

8. Die IESG KANN die Verantwortung für ein Protokoll-Token neu zuweisen. Dies wird normalerweise nur verwendet, wenn eine verantwortliche Partei nicht kontaktiert werden kann.