2. Conformance (Konformität)
2.1. Syntax Notation (Syntaxnotation)
Diese Spezifikation verwendet die erweiterte Backus-Naur-Form (Augmented Backus-Naur Form, ABNF) Notation von [RFC5234], erweitert um die Notation für Groß-/Kleinschreibung in Zeichenketten, die in [RFC7405] definiert ist.
Sie verwendet auch eine Listenerweiterung, die in Abschnitt 5.6.1 definiert ist und eine kompakte Definition von durch Kommas getrennten Listen unter Verwendung eines "#"-Operators ermöglicht (ähnlich wie der "*"-Operator Wiederholung anzeigt). Anhang A zeigt die gesammelte Grammatik mit allen auf die Standard-ABNF-Notation erweiterten Listenoperatoren.
Als Konvention bezeichnen ABNF-Regelnamen mit dem Präfix "obs-" veraltete Grammatikregeln, die aus historischen Gründen erscheinen.
Die folgenden Kernregeln sind durch Verweis enthalten, wie in Anhang B.1 von [RFC5234] definiert: ALPHA (Buchstaben), CR (Wagenrücklauf), CRLF (CR LF), CTL (Steuerzeichen), DIGIT (Dezimal 0-9), DQUOTE (doppeltes Anführungszeichen), HEXDIG (hexadezimal 0-9/A-F/a-f), HTAB (horizontaler Tabulator), LF (Zeilenvorschub), OCTET (beliebige 8-Bit-Datensequenz), SP (Leerzeichen) und VCHAR (jedes sichtbare US-ASCII-Zeichen).
Abschnitt 5.6 definiert einige generische syntaktische Komponenten für Feldwerte.
Diese Spezifikation verwendet die Begriffe "character" (Zeichen), "character encoding scheme" (Zeichencodierungsschema), "charset" (Zeichensatz) und "protocol element" (Protokollelement), wie sie in [RFC6365] definiert sind.
2.2. Requirements Notation (Anforderungsnotation)
Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (muss), "SHALL NOT" (darf nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "NOT RECOMMENDED" (nicht empfohlen), "MAY" (kann) und "OPTIONAL" (optional) in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
Diese Spezifikation zielt auf Konformitätskriterien gemäß der Rolle eines Teilnehmers in der HTTP-Kommunikation ab. Daher werden Anforderungen an Sender (Senders), Empfänger (Recipients), Clients (Clients), Server (Servers), Benutzeragenten (User Agents), Vermittler (Intermediaries), Ursprungsserver (Origin Servers), Proxies (Proxies), Gateways (Gateways) oder Caches (Caches) gestellt, je nachdem, welches Verhalten durch die Anforderung eingeschränkt wird. Zusätzliche Anforderungen werden an Implementierungen (Implementations), Ressourcenbesitzer (Resource Owners) und Protokollelement-Registrierungen (Protocol Element Registrations) gestellt, wenn sie über den Umfang einer einzelnen Kommunikation hinausgehen.
Das Verb "generate" (generieren) wird anstelle von "send" (senden) verwendet, wenn eine Anforderung nur für Implementierungen gilt, die das Protokollelement erstellen, und nicht für eine Implementierung, die ein empfangenes Element nach unten weiterleitet.
Eine Implementierung gilt als konform, wenn sie alle Anforderungen erfüllt, die mit den Rollen verbunden sind, die sie in HTTP übernimmt.
Ein Sender darf keine (MUST NOT) Protokollelemente generieren, die nicht mit der durch die entsprechenden ABNF-Regeln definierten Grammatik übereinstimmen. Innerhalb einer gegebenen Nachricht darf ein Sender keine (MUST NOT) Protokollelemente oder Syntaxalternativen generieren, die nur von Teilnehmern in anderen Rollen generiert werden dürfen (d. h. eine Rolle, die der Sender für diese Nachricht nicht hat).
Die Konformität mit HTTP umfasst sowohl die Konformität mit der speziellen Messaging-Syntax der verwendeten Protokollversion als auch die Konformität mit der Semantik der gesendeten Protokollelemente. Zum Beispiel wird ein Client, der Konformität mit HTTP/1.1 beansprucht, aber die für HTTP/1.1-Empfänger erforderlichen Funktionen nicht erkennt, nicht mit Servern interoperieren können, die ihre Antworten gemäß diesen Ansprüchen anpassen. Funktionen, die Benutzerauswahl widerspiegeln, wie Content-Negotiation (Content Negotiation) und vom Benutzer ausgewählte Erweiterungen, können das Anwendungsverhalten über den Protokollstrom hinaus beeinflussen; das Senden von Protokollelementen, die die Auswahl eines Benutzers ungenau widerspiegeln, wird den Benutzer verwirren und die Auswahl behindern.
Wenn eine Implementierung die semantische Konformität nicht erfüllt, werden die Empfänger der Nachrichten dieser Implementierung schließlich Workarounds (Workarounds) entwickeln, um ihr Verhalten entsprechend anzupassen. Ein Empfänger kann (MAY) solche Workarounds einsetzen und dabei konform zu diesem Protokoll bleiben, wenn die Workarounds auf die fehlerhaften Implementierungen beschränkt sind. Zum Beispiel scannen Server oft Teile des User-Agent-Feldwerts, und Benutzeragenten scannen oft den Server-Feldwert, um ihr eigenes Verhalten in Bezug auf bekannte Fehler oder schlecht gewählte Standardwerte anzupassen.
2.3. Length Requirements (Längenanforderungen)
Ein Empfänger sollte (SHOULD) ein empfangenes Protokollelement defensiv analysieren, mit nur marginalen Erwartungen, dass das Element seiner ABNF-Grammatik entspricht und in eine angemessene Puffergröße passt.
HTTP hat keine spezifischen Längenbeschränkungen für viele seiner Protokollelemente, da die angemessenen Längen stark variieren werden, abhängig vom Bereitstellungskontext und dem Zweck der Implementierung. Daher hängt die Interoperabilität zwischen Sendern und Empfängern von gemeinsamen Erwartungen darüber ab, was eine angemessene Länge für jedes Protokollelement ist. Darüber hinaus hat sich das, was allgemein als angemessene Länge für einige Protokollelemente verstanden wird, im Laufe der letzten drei Jahrzehnte der HTTP-Nutzung geändert und wird sich voraussichtlich auch in Zukunft weiter ändern.
Mindestens muss (MUST) ein Empfänger in der Lage sein, Protokollelementlängen zu analysieren und zu verarbeiten, die mindestens so lang sind wie die Werte, die er für dieselben Protokollelemente in anderen Nachrichten generiert. Zum Beispiel muss ein Ursprungsserver, der sehr lange URI-Referenzen auf seine eigenen Ressourcen veröffentlicht, in der Lage sein, dieselben Referenzen zu analysieren und zu verarbeiten, wenn sie als Ziel-URI empfangen werden.
Viele empfangene Protokollelemente werden nur in dem Maße analysiert, das notwendig ist, um dieses Element zu identifizieren und nach unten weiterzuleiten. Zum Beispiel könnte ein Vermittler ein empfangenes Feld in seine Feldnamen- und Feldwertkomponenten analysieren, das Feld dann aber ohne weitere Analyse innerhalb des Feldwerts weiterleiten.
2.4. Error Handling (Fehlerbehandlung)
Ein Empfänger muss (MUST) ein empfangenes Protokollelement gemäß der für es durch diese Spezifikation definierten Semantik interpretieren, einschließlich Erweiterungen zu dieser Spezifikation, es sei denn, der Empfänger hat (durch Erfahrung oder Konfiguration) festgestellt, dass der Sender das, was durch diese Semantik impliziert wird, falsch implementiert. Zum Beispiel könnte ein Ursprungsserver den Inhalt eines empfangenen Accept-Encoding-Header-Felds ignorieren, wenn die Inspektion des User-Agent-Header-Felds eine spezifische Implementierungsversion anzeigt, von der bekannt ist, dass sie beim Empfang bestimmter Content-Codierungen fehlschlägt.
Sofern nicht anders angegeben, kann (MAY) ein Empfänger versuchen, ein verwendbares Protokollelement aus einem ungültigen Konstrukt wiederherzustellen. HTTP definiert keine spezifischen Fehlerbehandlungsmechanismen, außer wenn sie direkte Auswirkungen auf die Sicherheit haben, da verschiedene Anwendungen des Protokolls unterschiedliche Fehlerbehandlungsstrategien erfordern. Zum Beispiel könnte ein Webbrowser transparent von einer Antwort wiederherstellen wollen, bei der das Location-Header-Feld nicht gemäß der ABNF analysiert wird, während ein Systemsteuerungsclient jede Form der Fehlerbehebung als gefährlich betrachten könnte.
Einige Anfragen können von einem Client im Falle eines zugrunde liegenden Verbindungsfehlers automatisch wiederholt werden, wie in Abschnitt 9.2.2 beschrieben.
2.5. Protocol Version (Protokollversion)
Die Versionsnummer von HTTP besteht aus zwei Dezimalziffern, die durch einen "." (Punkt oder Dezimalpunkt) getrennt sind. Die erste Ziffer (Hauptversion, Major Version) gibt die Messaging-Syntax an, während die zweite Ziffer (Nebenversion, Minor Version) die höchste Nebenversion innerhalb dieser Hauptversion angibt, mit der der Sender konform ist (in der Lage ist, für zukünftige Kommunikation zu verstehen).
Während sich die Kernsemantik von HTTP zwischen Protokollversionen nicht ändert, kann sich ihr Ausdruck "auf der Leitung" ändern, und daher ändert sich die HTTP-Versionsnummer, wenn inkompatible Änderungen am Leitungsformat vorgenommen werden. Darüber hinaus erlaubt HTTP inkrementelle, rückwärtskompatible Änderungen am Protokoll, ohne seine Version zu ändern, durch die Verwendung definierter Erweiterungspunkte (Abschnitt 16).
Die Protokollversion als Ganzes gibt die Konformität des Senders mit den in den entsprechenden Spezifikationen dieser Version festgelegten Anforderungen an. Zum Beispiel wird die Version "HTTP/1.1" durch die kombinierten Spezifikationen dieses Dokuments, "HTTP Caching" [CACHING] und "HTTP/1.1" [HTTP/1.1] definiert.
Die Hauptversionsnummer von HTTP wird erhöht, wenn eine inkompatible Nachrichtensyntax eingeführt wird. Die Nebennummer wird erhöht, wenn Änderungen am Protokoll vorgenommen werden, die den Effekt haben, die Nachrichtensemantik zu erweitern oder zusätzliche Fähigkeiten des Senders zu implizieren.
Die Nebenversion gibt die Kommunikationsfähigkeiten des Senders an, selbst wenn der Sender nur eine rückwärtskompatible Teilmenge des Protokolls verwendet, wodurch der Empfänger weiß, dass erweiterte Funktionen in der Antwort (von Servern) oder in zukünftigen Anfragen (von Clients) verwendet werden können.