8. IANA-Überlegungen (IANA Considerations)
Diese Spezifikation aktualisiert die durch [RFC2817], [RFC2818] und [RFC4229] etablierten Register und definiert zusätzlich neue Register für Methodennamen, Statuscodes und zugehörige Semantik.
8.1. Methodenregistrierung (Method Registration)
Das "Hypertext Transfer Protocol (HTTP) Method Registry" definiert den Namensraum für das Request-Methoden-Token (Abschnitt 4). Das Methodenregister wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-methods gepflegt.
8.1.1. Verfahren (Procedure)
Registrierungen MÜSSEN (MUST) die folgenden Felder enthalten:
- Methodenname (Method Name)
- Sicher (Safe) (ja/nein)
- Idempotent (ja/nein)
- Zeiger auf Spezifikationstext (Pointer to specification text)
Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe Abschnitt 4.1 von [RFC5226]).
8.1.2. Überlegungen für neue Methoden (Considerations for New Methods)
Standardisierte Methoden sind generisch; das heißt, sie sind potenziell auf jede Ressource anwendbar, nicht nur auf einen bestimmten Medientyp, eine Ressourcenart 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 Message-Parsing (Abschnitt 3 von [RFC7230]) 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 eines Message-Bodys in der Request- oder Response-Nachricht verbieten. Definitionen neuer Methoden können spezifizieren, dass nur ein Message-Body mit Länge Null erlaubt ist, indem sie ein Content-Length-Header-Feld mit einem Wert von "0" erfordern.
Eine neue Methodendefinition muss angeben, ob sie sicher ist (Abschnitt 4.2.1), idempotent (Abschnitt 4.2.2), cachebar (Abschnitt 4.2.3), welche Semantik mit dem Request-Message-Body (falls vorhanden) verbunden sein soll und welche Semantik mit dem Response-Message-Body (falls vorhanden) verbunden sein soll. Beachten Sie, dass die Idempotenz einer Request-Methode eine Eigenschaft der Implementierung auf dem Origin-Server ist. Da Implementierungen vom beabsichtigten Verhalten abweichen können, kann sich der Client nicht darauf verlassen, dass eine Methode idempotent oder sicher ist.
Wenn eine neue Methode cachebar ist, sollte (ought to) ihre Definition beschreiben, wie und unter welchen Bedingungen ein Cache eine Antwort speichern und sie verwenden kann, um eine nachfolgende Anfrage zu erfüllen. Eine neue Methode sollte (ought to) beschreiben, ob sie konditioniert werden kann (Abschnitt 5 von [RFC7232]) und, wenn ja, wie ein Server antwortet, wenn die Bedingung falsch ist. Ebenso sollte (ought to) eine neue Methode dies dokumentieren, wenn sie möglicherweise eine Verwendung für Partial-Response-Semantik ([RFC7233]) hat.
Hinweis: Vermeiden Sie die Definition eines Methodennamens, der mit "M-" beginnt, da dieses Präfix möglicherweise als die ihm durch [RFC2774] zugewiesene Semantik fehlinterpretiert wird.
8.1.3. Registrierungen (Registrations)
Das Methodenregistrierungsverfahren für HTTP wurde gemäß dieser Spezifikation aktualisiert. Das HTTP-Methodenregister wurde mit den folgenden Registrierungen aktualisiert:
| Methodenname | Sicher | Idempotent | Referenz |
|---|---|---|---|
| GET | ja | ja | Abschnitt 4.3.1 |
| HEAD | ja | ja | Abschnitt 4.3.2 |
| POST | nein | nein | Abschnitt 4.3.3 |
| PUT | nein | ja | Abschnitt 4.3.4 |
| DELETE | nein | ja | Abschnitt 4.3.5 |
| CONNECT | nein | nein | Abschnitt 4.3.6 |
| OPTIONS | ja | ja | Abschnitt 4.3.7 |
| TRACE | ja | ja | Abschnitt 4.3.8 |
8.2. Statuscode-Registrierung (Status Code Registration)
Das "Hypertext Transfer Protocol (HTTP) Status Code Registry" definiert den Namensraum für das Response-Statuscode-Token (Abschnitt 6). Das Statuscode-Register wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-status-codes gepflegt.
8.2.1. Verfahren (Procedure)
Registrierungen MÜSSEN (MUST) die folgenden Felder enthalten:
- Statuscode (Status Code) (3 Ziffern)
- Kurzbeschreibung (Short Description)
- Zeiger auf Spezifikationstext (Pointer to specification text)
Werte, die zum HTTP-Statuscode-Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe Abschnitt 4.1 von [RFC5226]).
8.2.2. Überlegungen für neue Statuscodes (Considerations for New Status Codes)
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 Ressourcenart 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 6 definierten Kategorien fallen. Um bestehenden Parsern die Verarbeitung der Response-Nachricht zu ermöglichen, können neue Statuscodes eine Payload nicht verbieten, obwohl sie einen Payload-Body mit Länge Null vorschreiben können.
Vorschläge für neue Statuscodes, die noch nicht weit verbreitet sind, sollten (ought to) die Zuweisung einer spezifischen Nummer für den Code vermeiden, bis ein klarer Konsens besteht, dass er registriert wird; stattdessen können frühe Entwürfe eine Notation wie "4NN" oder "3N0" verwenden, um die Klasse der vorgeschlagenen Statuscodes anzugeben, ohne vorzeitig eine Nummer zu verbrauchen.
Die Definition eines neuen Statuscodes sollte (ought to) die Semantik von Antworten mit diesem Statuscode erklären, einschließlich aller erforderlichen Vorbedingungen, der Request-Charakteristika, die den Status ausgelöst haben, und des erwarteten Client-Verhaltens für die Verarbeitung solcher Antworten.
8.2.3. Registrierungen (Registrations)
Das Statuscode-Register wurde mit den folgenden Registrierungen aktualisiert:
| Wert | Beschreibung | Referenz |
|---|---|---|
| 100 | Continue | Abschnitt 6.2.1 |
| 101 | Switching Protocols | Abschnitt 6.2.2 |
| 200 | OK | Abschnitt 6.3.1 |
| 201 | Created | Abschnitt 6.3.2 |
| 202 | Accepted | Abschnitt 6.3.3 |
| 203 | Non-Authoritative Information | Abschnitt 6.3.4 |
| 204 | No Content | Abschnitt 6.3.5 |
| 205 | Reset Content | Abschnitt 6.3.6 |
| 206 | Partial Content | [RFC7233], Abschnitt 4.1 |
| 300 | Multiple Choices | Abschnitt 6.4.1 |
| 301 | Moved Permanently | Abschnitt 6.4.2 |
| 302 | Found | Abschnitt 6.4.3 |
| 303 | See Other | Abschnitt 6.4.4 |
| 304 | Not Modified | [RFC7232], Abschnitt 4.1 |
| 305 | Use Proxy | Abschnitt 6.4.5 |
| 306 | (Unused) | Abschnitt 6.4.6 |
| 307 | Temporary Redirect | Abschnitt 6.4.7 |
| 400 | Bad Request | Abschnitt 6.5.1 |
| 401 | Unauthorized | [RFC7235], Abschnitt 3.1 |
| 402 | Payment Required | Abschnitt 6.5.2 |
| 403 | Forbidden | Abschnitt 6.5.3 |
| 404 | Not Found | Abschnitt 6.5.4 |
| 405 | Method Not Allowed | Abschnitt 6.5.5 |
| 406 | Not Acceptable | Abschnitt 6.5.6 |
| 407 | Proxy Authentication Required | [RFC7235], Abschnitt 3.2 |
| 408 | Request Timeout | Abschnitt 6.5.7 |
| 409 | Conflict | Abschnitt 6.5.8 |
| 410 | Gone | Abschnitt 6.5.9 |
| 411 | Length Required | Abschnitt 6.5.10 |
| 412 | Precondition Failed | [RFC7232], Abschnitt 4.2 |
| 413 | Payload Too Large | Abschnitt 6.5.11 |
| 414 | URI Too Long | Abschnitt 6.5.12 |
| 415 | Unsupported Media Type | Abschnitt 6.5.13 |
| 416 | Range Not Satisfiable | [RFC7233], Abschnitt 4.4 |
| 417 | Expectation Failed | Abschnitt 6.5.14 |
| 426 | Upgrade Required | Abschnitt 6.5.15 |
| 500 | Internal Server Error | Abschnitt 6.6.1 |
| 501 | Not Implemented | Abschnitt 6.6.2 |
| 502 | Bad Gateway | Abschnitt 6.6.3 |
| 503 | Service Unavailable | Abschnitt 6.6.4 |
| 504 | Gateway Timeout | Abschnitt 6.6.5 |
| 505 | HTTP Version Not Supported | Abschnitt 6.6.6 |
8.3. Header-Feld-Registrierung (Header Field Registration)
Diese Spezifikation aktualisiert das in [RFC4229] definierte HTTP-Header-Feld-Register mit dem Registrierungsverfahren von [RFC3864].
8.3.1. Überlegungen für neue Header-Felder (Considerations for New Header Fields)
Header-Felder sind Schlüsselkomponenten des HTTP-Erweiterbarkeitsframeworks. Sie definieren zusätzliche Daten, die entweder mit einer Nachricht oder einer Ressource verbunden sind. Bei der Definition eines neuen Header-Felds müssen viele Überlegungen angestellt werden.
Neue Header-Felder müssen mindestens Folgendes definieren:
- Den Feldnamen (Abschnitt 3.2 von [RFC7230])
- Die erwartete Grammatik des Feldwerts
- Die Semantik des Felds
- Für Request-Header-Felder, wie sie die Message-Semantik überschreiben oder erweitern können
- Für Response-Header-Felder, wie sie die Interpretation der Response modifizieren
- Ob das Feld von einem Cache gespeichert werden sollte und ob es in Antworten auf nachfolgende Anfragen zurückgegeben werden kann
- Ob das Feld von Proxys weitergeleitet werden sollte
Es ist auch nützlich, Folgendes zu dokumentieren:
- Ob das Header-Feld für die Verwendung durch Intermediäre oder nur End-to-End vorgesehen ist
- Sicherheits- und Datenschutzüberlegungen (siehe Abschnitt 9)
- Interaktion mit anderen Header-Feldern
Detaillierte Ratschläge zur Definition neuer Header-Felder sind in "Guidelines for HTTP Header Field Specifications" [RFC6648bis] verfügbar.
8.3.2. Registrierungen (Registrations)
Das "Hypertext Transfer Protocol (HTTP) Header Field Registry" unter http://www.iana.org/assignments/message-headers/ sollte mit den folgenden permanenten Registrierungen aktualisiert werden (siehe [RFC3864]):
| Header-Feldname | Protokoll | Status | Referenz |
|---|---|---|---|
| Accept | http | standard | Abschnitt 5.3.2 |
| Accept-Charset | http | standard | Abschnitt 5.3.3 |
| Accept-Encoding | http | standard | Abschnitt 5.3.4 |
| Accept-Language | http | standard | Abschnitt 5.3.5 |
| Allow | http | standard | Abschnitt 7.4.1 |
| Content-Encoding | http | standard | Abschnitt 3.1.2.2 |
| Content-Language | http | standard | Abschnitt 3.1.3.2 |
| Content-Location | http | standard | Abschnitt 3.1.4.2 |
| Content-Type | http | standard | Abschnitt 3.1.1.5 |
| Date | http | standard | Abschnitt 7.1.1.2 |
| Expect | http | standard | Abschnitt 5.1.1 |
| From | http | standard | Abschnitt 5.5.1 |
| Location | http | standard | Abschnitt 7.1.2 |
| Max-Forwards | http | standard | Abschnitt 5.1.2 |
| MIME-Version | http | standard | Anhang A.1 |
| Referer | http | standard | Abschnitt 5.5.2 |
| Retry-After | http | standard | Abschnitt 7.1.3 |
| Server | http | standard | Abschnitt 7.4.2 |
| User-Agent | http | standard | Abschnitt 5.5.3 |
| Vary | http | standard | Abschnitt 7.1.4 |
Der Change Controller ist: "IETF ([email protected]) - Internet Engineering Task Force".
8.4. Content-Coding-Registrierung (Content Coding Registration)
Das "HTTP Content Coding Registry" definiert den Namensraum für Content-Coding-Namen (Abschnitt 3.1.2.1). Das Content-Coding-Register wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-parameters gepflegt.
8.4.1. Verfahren (Procedure)
Registrierungen MÜSSEN (MUST) die folgenden Felder enthalten:
- Name
- Beschreibung (Description)
- Zeiger auf Spezifikationstext (Pointer to specification text)
Namen, die mit "x-" beginnen, sind für Private Use reserviert (wie durch [RFC5226] definiert) und können daher nicht registriert werden.
Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe Abschnitt 4.1 von [RFC5226]).
8.4.2. Registrierungen (Registrations)
Das Content-Coding-Register wurde mit den folgenden Registrierungen aktualisiert:
| Name | Beschreibung | Referenz |
|---|---|---|
| compress | UNIX "compress" Datenformat | Abschnitt 3.1.2.1 |
| deflate | "deflate" komprimierte Daten | Abschnitt 3.1.2.1 |
| gzip | GZIP-Dateiformat | Abschnitt 3.1.2.1 |
| identity | Reserviert (Synonym für keine Kodierung) | Abschnitt 3.1.2.1 |