Anhang A. HTTP-Versionsgeschichte
HTTP ist seit 1990 in Gebrauch. Die erste Version, später als HTTP/0.9 bezeichnet, war ein einfaches Protokoll für die Übertragung von Hypertextdaten über das Internet, das nur eine einzige Anforderungsmethode (GET) und keine Metadaten verwendete. HTTP/1.0, wie in [RFC1945] definiert, fügte eine Reihe von Anforderungsmethoden und MIME-ähnliche Nachrichtenübermittlung hinzu, wodurch Metadaten übertragen und Modifizierer auf die Anforderungs-/Antwortsemantik gesetzt werden konnten. HTTP/1.0 berücksichtigte jedoch nicht ausreichend die Auswirkungen hierarchischer Proxys, des Cachings, der Notwendigkeit persistenter Verbindungen oder namensbasierter virtueller Hosts. Die Verbreitung unvollständig implementierter Anwendungen, die sich selbst "HTTP/1.0" nannten, machte eine Änderung der Protokollversion weiterhin erforderlich, damit zwei kommunizierende Anwendungen die tatsächlichen Fähigkeiten der jeweils anderen bestimmen können.
HTTP/1.1 bleibt mit HTTP/1.0 kompatibel, indem es strengere Anforderungen enthält, die zuverlässige Implementierungen ermöglichen, und nur solche Funktionen hinzufügt, die entweder von einem HTTP/1.0-Empfänger sicher ignoriert werden können oder nur bei der Kommunikation mit einer Partei gesendet werden, die Konformität mit HTTP/1.1 angibt.
HTTP/1.1 wurde so gestaltet, dass die Unterstützung früherer Versionen einfach ist. Ein universeller HTTP/1.1-Server sollte in der Lage sein, jede gültige Anfrage im Format von HTTP/1.0 zu verstehen und angemessen mit einer HTTP/1.1-Nachricht zu antworten, die nur Funktionen verwendet, die von HTTP/1.0-Clients verstanden (oder sicher ignoriert) werden. Ebenso kann von einem HTTP/1.1-Client erwartet werden, dass er jede gültige HTTP/1.0-Antwort versteht.
Da HTTP/0.9 keine Header-Felder in einer Anfrage unterstützte, gibt es keinen Mechanismus für es, namensbasierte virtuelle Hosts zu unterstützen (Auswahl einer Ressource durch Prüfung des Header-Felds Host). Jeder Server, der namensbasierte virtuelle Hosts implementiert, sollte die Unterstützung für HTTP/0.9 deaktivieren. Die meisten Anfragen, die wie HTTP/0.9 erscheinen, sind tatsächlich schlecht aufgebaute HTTP/1.x-Anfragen, die dadurch entstehen, dass ein Client das Anfrageziel nicht ordnungsgemäß kodiert.
A.1. Änderungen gegenüber HTTP/1.0
Dieser Abschnitt fasst die wichtigsten Unterschiede zwischen den Versionen HTTP/1.0 und HTTP/1.1 zusammen.
A.1.1. Web-Server mit mehreren Hosts (Multihomed)
Die Anforderungen, dass Clients und Server das Header-Feld Host unterstützen (Abschnitt 5.4), einen Fehler melden, wenn es in einer HTTP/1.1-Anfrage fehlt, und absolute URIs akzeptieren (Abschnitt 5.3), gehören zu den wichtigsten durch HTTP/1.1 definierten Änderungen.
Ältere HTTP/1.0-Clients nahmen eine Eins-zu-eins-Beziehung von IP-Adressen und Servern an; es gab keinen anderen etablierten Mechanismus, um den beabsichtigten Server einer Anfrage zu unterscheiden, als die IP-Adresse, an die diese Anfrage gerichtet war. Das Header-Feld Host wurde während der Entwicklung von HTTP/1.1 eingeführt und, obwohl es von den meisten HTTP/1.0-Browsern schnell implementiert wurde, wurden zusätzliche Anforderungen an alle HTTP/1.1-Anfragen gestellt, um eine vollständige Übernahme sicherzustellen. Zum Zeitpunkt dieses Schreibens sind die meisten HTTP-basierten Dienste für das Targeting von Anfragen vom Header-Feld Host abhängig.
A.1.2. Keep-Alive-Verbindungen
In HTTP/1.0 wird jede Verbindung vom Client vor der Anfrage aufgebaut und vom Server nach dem Senden der Antwort geschlossen. Einige Implementierungen implementieren jedoch die ausdrücklich ausgehandelte ("Keep-Alive") Version persistenter Verbindungen, die in Abschnitt 19.7.1 von [RFC2068] beschrieben ist.
Einige Clients und Server möchten möglicherweise mit diesen früheren Ansätzen für persistente Verbindungen kompatibel sein, indem sie sie ausdrücklich mit einem Anforderungs-Header-Feld "Connection: keep-alive" aushandeln. Einige experimentelle Implementierungen persistenter Verbindungen in HTTP/1.0 sind jedoch fehlerhaft; wenn beispielsweise ein HTTP/1.0-Proxy-Server Connection nicht versteht, leitet er dieses Header-Feld fälschlicherweise an den nächsten inbound-Server weiter, was zu einer hängenden Verbindung führen würde.
Eine versuchte Lösung war die Einführung eines Header-Felds Proxy-Connection, das speziell auf Proxys abzielte. In der Praxis war dies ebenfalls nicht praktikabel, weil Proxys oft in mehreren Schichten eingesetzt werden, was zum selben oben erörterten Problem führt.
Daher werden Clients ermutigt, das Header-Feld Proxy-Connection in keiner Anfrage zu senden.
Clients werden außerdem ermutigt, die Verwendung von Connection: keep-alive in Anfragen sorgfältig abzuwägen; obwohl sie persistente Verbindungen mit HTTP/1.0-Servern ermöglichen können, müssen Clients, die sie verwenden, die Verbindung auf "hängende" Anfragen überwachen (die anzeigen, dass der Client aufhören sollte, das Header-Feld zu senden), und dieser Mechanismus sollte von Clients überhaupt nicht verwendet werden, wenn ein Proxy verwendet wird.
A.1.3. Einführung von Transfer-Encoding
HTTP/1.1 führt das Header-Feld Transfer-Encoding ein (Abschnitt 3.3.1). Transferkodierungen müssen dekodiert werden, bevor eine HTTP-Nachricht über ein MIME-konformes Protokoll weitergeleitet wird.
A.2. Änderungen gegenüber RFC 2616
Der Umgang von HTTP mit Fehlerbehandlung wurde erläutert. (Abschnitt 2.5)
Die ABNF-Produktion HTTP-version wurde dahingehend klargestellt, dass sie case-sensitiv ist. Darüber hinaus wurden Versionsnummern auf einzelne Ziffern beschränkt, da bekannt ist, dass Implementierungen mehrstellige Versionsnummern falsch behandeln. (Abschnitt 2.6)
Userinfo (d. h. Benutzername und Passwort) sind nun in HTTP- und HTTPS-URIs unzulässig, wegen Sicherheitsproblemen im Zusammenhang mit ihrer Übertragung über die Leitung. (Abschnitt 2.7.1)
Das HTTPS-URI-Schema wird nun durch diese Spezifikation definiert; zuvor geschah dies in Abschnitt 2.4 von [RFC2818]. Darüber hinaus impliziert es Ende-zu-Ende-Sicherheit. (Abschnitt 2.7.2)
HTTP-Nachrichten können von Implementierungen gepuffert werden (und werden es oft); obwohl sie manchmal als Stream verfügbar sind, ist HTTP grundsätzlich ein nachrichtenorientiertes Protokoll. Es wurden Mindestunterstützungsgrößen für verschiedene Protokollelemente vorgeschlagen, um die Interoperabilität zu verbessern. (Abschnitt 3)
Ungültiger Whitespace um Feldnamen muss nun zurückgewiesen werden, da seine Akzeptanz eine Sicherheitslücke darstellt. Die ABNF-Produktionen, die Header-Felder definieren, listen nun nur noch den Feldwert auf. (Abschnitt 3.2)
Regeln über impliziten linearen Whitespace zwischen bestimmten Grammatikproduktionen wurden entfernt; nun ist Whitespace nur dort erlaubt, wo er in der ABNF ausdrücklich definiert ist. (Abschnitt 3.2.3)
Header-Felder, die sich über mehrere Zeilen erstrecken ("Zeilenfaltung"), sind veraltet. (Abschnitt 3.2.4)
Das NUL-Oktett ist im Kommentar- und quoted-string-Text nicht mehr erlaubt, und die Behandlung von Backslash-Escaping darin wurde klargestellt. Die Regel quoted-pair erlaubt nun nicht mehr das Escapen von Steuerzeichen außer HTAB. Nicht-US-ASCII-Inhalt in Header-Feldern und in der reason-phrase wurde veraltet und undurchsichtig gemacht (die Regel TEXT wurde entfernt). (Abschnitt 3.2.6)
Falsche Content-Length-Header-Felder müssen nun von Empfängern als Fehler behandelt werden. (Abschnitt 3.3.2)
Der Algorithmus zur Bestimmung der Nachrichtenkörperlänge wurde klargestellt, um alle Sonderfälle (z. B. durch Methoden oder Statuscodes bedingt) anzuzeigen, die ihn beeinflussen, und dass neue Protokollelemente solche Sonderfälle nicht definieren können. CONNECT ist ein neuer Sonderfall bei der Bestimmung der Nachrichtenkörperlänge. "multipart/byteranges" ist keine Möglichkeit mehr zur Bestimmung der Nachrichtenkörperlängen-Erkennung. (Abschnitt 3.3.3)
Das Token der "identity"-Transferkodierung wurde entfernt. (Abschnitte 3.3 und 4)
Die Chunk-Länge enthält nicht die Anzahl der Oktette im Chunk-Header und -Trailer. Zeilenfaltung in Chunk-Erweiterungen ist unzulässig. (Abschnitt 4.1)
Die Bedeutung der "deflate"-Inhaltskodierung wurde klargestellt. (Abschnitt 4.2.2)
Die Segment- + Query-Komponenten von RFC 3986 wurden verwendet, um das Anfrageziel zu definieren, statt abs_path aus RFC 1808. Die asterisk-form des Anfrageziels ist nur mit der Methode OPTIONS erlaubt. (Abschnitt 5.3)
Der Begriff "Effective Request URI" wurde eingeführt. (Abschnitt 5.5)
Gateways müssen keine Header-Felder Via mehr erzeugen. (Abschnitt 5.7.1)
Es wurde klargestellt, wann genau "close"-Verbindungsoptionen gesendet werden müssen. Außerdem müssen "hop-by-hop"-Header-Felder im Header-Feld Connection erscheinen; nur weil sie in dieser Spezifikation als hop-by-hop definiert sind, sind sie nicht davon ausgenommen. (Abschnitt 6.1)
Die Grenze von zwei Verbindungen pro Server wurde entfernt. Eine idempotente Abfolge von Anfragen muss nicht mehr wiederholt werden. Die Anforderung, Anfragen unter bestimmten Umständen zu wiederholen, wenn der Server die Verbindung vorzeitig schließt, wurde entfernt. Außerdem wurden einige überflüssige Anforderungen dazu entfernt, wann Server Verbindungen vorzeitig schließen dürfen. (Abschnitt 6.3)
Die Semantik des Header-Felds Upgrade wird nun auch in anderen Antworten als 101 definiert (dies wurde aus [RFC2817] übernommen). Darüber hinaus ist die Reihenfolge im Feldwert nun signifikant. (Abschnitt 6.7)
Leere Listenelemente in Listenproduktionen (z. B. ein Listen-Header-Feld, das ", ," enthält) sind veraltet. (Abschnitt 7)
Die Registrierung von Transfer Codings erfordert nun IETF Review (Abschnitt 8.4)
Diese Spezifikation definiert nun das Upgrade Token Registry, das zuvor in Abschnitt 7.2 von [RFC2817] definiert wurde. (Abschnitt 8.6)
Die Erwartung, HTTP/0.9-Anfragen zu unterstützen, wurde entfernt. (Anhang A)
Probleme mit den Header-Feldern Keep-Alive und Proxy-Connection in Anfragen werden aufgezeigt, wobei von der Verwendung des letzteren gänzlich abgeraten wird. (Anhang A.1.2)