Hauptseminar
»Die
Metamorphosen von HTML« (SS 2000)
Betreuer: Tim Geisler
Sitzung am: 31. Juli 2000
Thema: HTTP: Hypertext Transfer Protocol
Referenten: Tim Furche
Fehlermeldungen, Nachfragen und Korrekturen bitte an den Referenten.
In dieser Arbeit soll eine Einführung in Design und Funktionalität des Hypertext Transfer Protocols (HTTP)
gegeben werden. Besondere Bedeutung erhält dabei die Diskussion der verschiedenen Designanforderungen an HTTP
und deren Realisierung. In diesem Zusammenhang wird ausführlich auf die Entwicklung von HTTP/1.1 eingegangen
(Persistent Connection, Pipelining etc.).
Schließlich werden einige zukünftige Einsatzgebiete und Anforderungen von HTTP dargelegt und eine mögliche
Entwicklung im Rahmen des HTTP-ng-Projektes skizziert.
Nachdem in den vorangegangenen Vorträgen Art und Weise der Beschreibung und Präsentation von Information (Inhalt) für das WWW im Zentrum der Betrachtung gestanden hat, soll in diesem Vortrag die Kommunikationssprache des WWW Thema sein: Von der Frage nach der Strukturierung und Darstellung von Daten und Dokumenten kommen wir nun dazu, zu fragen, wie diese Daten (z.B. Hypertext-Dokumente) zum Nutzer transferiert werden.
Bevor die eigentliche Kommunikationssprache betrachtet wird, ist es nützlich, die Eigenschaften und Anforderungen an eine solche Sprache zu betrachten. Da diese Sprache zur Kommunikation zwischen Anwendungen bzw. Geräten dienen soll, muß ihre Definition offensichtlich sehr viel genauere Angaben über die zugelassenen Konstrukte der Sprache und deren Bedeutung (also Interpretation) treffen. Weiterhin muß neben der reinen Sprache auch das Verhalten der Kommunikationspartner (wie sie auf bestimmte Nachrichten reagieren) definiert werden. Dies geschieht üblicherweise mit Hilfe eines Protokolls:
Ein »Protokoll« ist allgemein eine Definition von Regeln für die Kommunikation zwischen mehreren Entitäten. Insbesondere muß ein Protokoll festlegen, auf welche Weise die Kommunikation initiiert und beendet werden kann, welche Konstrukte Teile der Kommunikation sein dürfen und wie die Kommunikationspartner auf die unterschiedlichen Konstrukte reagieren sollen.
Wenn man nun ein Protokoll für den Transfer von Dokumenten definieren möchte, so muß man sich zuerst überlegen, wer an der Kommunikation beteiligt sein soll (Kommunikationspartner). Im Rahmen des Transfers von Dokumenten ist diese Antwort recht schnell gefunden: Die Kommunikation findet zwischen genau einem Nutzer und genau einem Diensterbringer, der das Dokument zur Verfügung stellt, statt. Natürlich wird die eigentliche Kommunikation zwischen dem sogenannten »User Agent«, der die Anforderungen des Nutzers in die verwendete Kommunikationssprache übersetzt, und einem Dienstserver, der die Anfragen verarbeitet und eine Antwort generiert, stattfinden, so daß weder Diensterbringer noch Nutzer eine genaue Kenntnis des zur Kommunikation verwendeten Protokolls benötigen (vgl. Abbildung 1).
Mit Hilfe dieser grundlegenden Architektur kann man nun leicht einige wesentliche Anforderungen an ein Transfer Protokoll für Ressourcen (z.B. Dokumente, Bilder, Dateien etc.) in einem weltweiten Netz aufstellen:
Ausgehend von den vorgestellten Anforderungen an ein Transferprotokoll für Ressourcen im Internet soll nun die tatsächliche Lösung, wie sie von Tim Berners-Lee 1990/91 vorgestellt und seither umfassend weiterentwickelt und verändert wurde, vorgestellt werden: HTTP. HTTP ist die standardisierte Abkürzung für das »Hypertext Transfer Protocol«, wie sie als Schema-Name in URLs (vgl. Abschnitt Ex. 1) verwendet werden darf.
Bevor wir die Realisierung und Architektur von HTTP genauer betrachten, soll der Aufgabenbereich von HTTP innerhalb der Internet-Protokolle noch einmal verdeutlicht werden. Dazu betrachte man zuerst das folgende Beispiel für einen Transfervorgang:
Angenommen ein Student möchte ein Buch bestellen. Dazu muß der Besteller (Client) das gewünschte Buch (die gewünschte Ressource) dem Verkäufer (Server) gegenüber spezifizieren. Dieser besorgt das Buch (die Daten) und sendet sie, abhängig von den Wünschen (Parametern) des Kunden (z.B. Zeit der Versendung, Verpackung, Lieferant etc.) über den Lieferanten an diesen (vgl. Abbildung 2). Entscheidend ist, daß für dieses Protokoll irrelevant ist, wie der Lieferant das Buch ausliefert (z.B. mit welchem Verkehrsmittel, auf welcher Route etc.). Von Interesse ist einzig und allein, daß der Lieferant das Buch zuverlässig in einer geeigneten Zeitspanne ausliefert.
Diese Charakteristika treffen weitgehend auch auf HTTP zu: Der Client spezifiziert nur welche Daten ihn interessieren (mittels der URL) und reichert diese Anfrage u.U. noch mit Informationen über seine Wünsche (Datenformat etc.) an. Der Server greift nach den Wünschen des Clients auf die Daten zu und sendet diese mit Hilfe eines zuverlässigen Lieferantens (TCP, vgl. Definition im folgenden Abschnitt) an den Client zurück.
Um die Architektur von HTTP zu verstehen ist es nötig einige Begriffe klar zu definieren (nach [Stal 2000] und [RFC 2616]).
Mit Hilfe der eben definierten Begriffe können wir nun die Struktur der Kommunikation von HTTP genauer betrachten. HTTP verwendet grundsätzlich drei Formen der Verbindung, wie sie in Abbildung 3 dargestellt sind:
Tatsächlich hat sich gerade diese Vielfalt an Verbindungsmöglichkeiten als ein entscheidender Faktor für den raschen Erfolg von HTTP erwiesen, da durch die zweite Verbindungsform etablierte Internetprotokolle (wie FTP) und Legacy-Systeme leicht integriert werden konnten, während die dritte Verbindungsform den Netzverkehr (vor allem aus großen Organisationen) deutlich reduzieren kann.
Es gibt also, wie bereits festgstellt, drei Typen von Mittlern (Intermediates), wie in Abbildung 4:
Schon kurz nach der Einführung von HTTP ist deutlich geworden, daß ein in der Informatik weit verbreitetes Konzept auch für den Zugriff auf Ressourcen im Internet gilt: Nutzer (insbesondere innerhalb einer Organisation) neigen dazu, auf Ressourcen, auf die sie (oder ein anderer Angestellter, Student etc.) bereits zugegriffen haben, erneut zuzugreifen. Dieses Prinzip wird als Lokalität bezeichnet, ihm wird durch die Verwendung von Caches Rechnung getragen.
In einem Cache kann ein Programm Antwort-Nachrichten (i.a. Ressourcen wie Hypertext-Dokumente) verschiedener Server speichern, so daß bei einem erneuten Zugriff nicht die komplette Antwort-Nachricht erneut übertragen werden muß.
Beispiel: Angenommen zwei Benutzer A und B nutzen einen gemeinsamen Cache. Greift nun Benutzer A auf eine (cachebare) Ressource zu, so wird diese vom Origin Server geholt und im Cache gespeichert. Greift dann Benutzer B darauf zu, so muß die Ressource nicht erneut vom Origin Server geladen werden, sondern kann direkt an den Benutzer weitergegeben werden (vgl. Abbildung 5). Dadurch wird der Zugriff schneller und die Netzlast nimmt ab.
Tatsächlich hat es sich gezeigt, daß durch die intelligente Verwendung von Caches (z.B. in Proxy implementiert) der Verkehr im Internet deutlich reduziert werden kann. Um Caching effizient und sinnvoll (so sollte einen Ressource nur dann aus dem Cache gelesen werden, wenn sie sich in der Zwischenzeit nicht geändert hat) sowohl in End-Geräten (z.B. Browsern) als auch in Proxies zu unterstützen, sind einige Änderungen am ursprünglichen Entwurf von HTTP erforderlich gewesen (vgl. Abschnitt 3.2 und 3.3.2). Insbesondere muß einiger Aufwand in Kauf genommen werden, um zu verhindern, daß der Cache semantisch intransparent wirkt, also Ressourcen in anderer Form liefert als bei einem Zugriff ohne Cache (vgl. auch Abschnitt 3.3.2).
Nachdem wir nun gesehen haben, auf welche Weise die Kommunikation in HTTP strukturiert werden kann, ist es nötig kurz darauf einzugehen, wie der eigentliche Transport der Daten stattfindet.
Einer der großen Vorteile eines sauber definierten Protokolls ist es, daß seine Dienste selbst wieder zur Implementierung von Protokollen für Dienste höherer Ebene realisiert werden können. Dadurch ergibt sich eine Hierarchie oder Schichtung der benötigten Protokolle. Im Rahmen des Internets ist dies der TCP/IP-Protokollstack, innerhalb dessen HTTP ein Protokoll der Anwendungsschicht (Application Layer), wie in Abbildung 6 dargestellt:
Man kann der Abbildung zweierlei entnehmen: Zum einen sieht man, daß bei der Nutzung von HTTP nicht nur der Overhead durch den HTTP-Header, wie er in Abschnit 3.2 skizziert wird, sondern zusätzlich noch die Steuerinformationen für TCP, IP und eventuell darunterliegende Protokolle (z.B. ATM) übertragen werden müssen. Andererseits bietet eine solche Schichtung einen weiteren Vorteil: Solange sich das Interface gegenüber der nächsthöheren Schicht nicht ändert, können Protokolle der unterliegenden Schichten ausgetauscht werden, ohne daß die Protokolle der höheren Schichten verändert werden müssen. Dies ist z.B. bei TLS (als Ersatz für TCP) geschehen und für die (daher hier auch nicht spezifizierten) Network-Access-Protokolle üblich.
Diese Einführung soll durch eine Beispielsitzung abgeschlossen werden, in der die einfachste Syntax einer HTTP
Anfrage und der darauf folgenden Antwort dargestellt ist.
Im folgenden werden Sitzungsprotokolle mit Hilfe von telnet
erzeugt, da so die Syntax von HTTP, die
von üblichen User Agents verborgen wird, sichtbar wird. Eingaben des Benutzers seien durch farbigen
Fettdruck und der Inhalt der HTTP-Antwort durch grünen Schriftzug markiert. Weitgehend sollten sich diese
Sitzungen auf jedem UNIX-System mit Anschluß an das Internet nachvollziehen lassen, während die Windows-Version von
telnet
die Statusinformationen ausspart und daher für unsere Zwecke nicht geeignet ist.
tim@orodreth:~> telnet www.informatik.uni-muenchen.de 80 Trying 141.84.220.200... Connected to www.informatik.uni-muenchen.de. Escape character is '^]'. GET / <html> <head><title>Informatik LMU München</title></head> <frameset rows="28,*,28" border=1 frameborder=0 framespacing=0> <frame src="ifirahmen-kopfzeile.html" name="ifirahmen_kopf" marginwidth=0 marginheight=0 scrolling=no> <frame src="index-d.html" name="ifirahmen_inhalt"> <frame src="ifirahmen-fusszeile.html" name="ifirahmen_fuss"> <noframes> [...] </noframes> </html> Connection closed by foreign host.
In dieser Sitzung ist also GET /
die Anfrage, mit deren Hilfe eine Ressource angefordert wird. Diese
Ressource wird als Antwort (ohne weitere (Meta-) Informationen) übertragen. Man beachte auch, daß nach der
Übertragung der Server (foreign host) unmittelbar die Verbindung bendet (vgl. Abschnitt 3.1).
Hier ist Telnet der User Agent, während der Server durch den beim Aufruf von telnet
gegebenen Hostnamen und Port bezeichnet wird.
Nach diesem kurzen Überblick über die wesentlichen Merkmale der Kommunikation mittels HTTP sei nun ein Blick auf die Entwicklung seit seiner Einführung 1990/91 gestattet.
Begonnen hat die Entwicklung von HTTP, wie nicht anders zu erwarten, mit Tim Berners-Lee am CERN in den Jahren 1990/1991 (vgl. [HTTP 0.9]). Berners-Lee benötigte für sein Hypertext-System ein Transfer-Protokoll und erkannte richtigerweise, daß keines der zu diesem Zeitpunkt etablierten Transfer-Protokoll für seine Arbeit geeignet war (man Vergleiche die Anforderungsliste aus Abschnitt 1.1). Insbesondere wurde FTP aufgrund seiner Komplexität (Authentifizierung, Verbindungsorientierung etc.) für ungeeignet befunden, Berners-Lee wollte in erster Linie ein extrem einfaches Protokoll implementieren.
Aus dieser Motivation heraus entstand die ursprüngliche Implementation von HTTP, die mittlerweile als HTTP/0.9 bezeichnet wird. Die gesamte Beschreibung dieses Protokolls umfaßt nur wenige Seiten (der aktuelle Standard 180-230 Seiten): Ein Client baut eine Verbindung zu einem Server über TCP an Port 80 auf. Der Client sendet genau eine Anfrage in einer der beiden folgenden Formen:
GET document.html CRLF GET document.html?help+me CRLF
Jede Anfrage beginnt also mit dem Wort GET
, der sogenannten Methode. Keine
weiteren Methoden werden unterstützt. Auf die Methode folgt, getrennt durch genau ein Leerzeichen, der Name des
Hypertext-Dokuments, gefolgt durch ein CRLF
als Zeilenendezeichen. Alternativ kann der Dokumentname
durch einen Suchstring, der vom eigentlichen Dokumentnamen durch ein ?
getrennt sein muß, erweitert
werden, wobei mehrere Suchstrings durch +
getrennt angegeben werden können.
Der Server darf als Antwort ausschließlich den Inhalt des Dokuments ohne jegliche Metainformationen (wie Format
des Inhalts) übertragen, wobei das Dokument ausschließlich HTML-Hypertext enthalten darf. Nach der Übertragung
des Inhalts muß der Server unmittelbar die Verbindung schließen, um das Ende des Dokuments
anzuzeigen. Dies ist notwendig, da keine Information über die Länge des Dokuments übertragen wird und auch kein
beliebiges Dokumentendezeichen verwendet werden kann.
Es dürfte offensichtlich sein, daß die Implementation dieses Protokolls tatsächlich trivial ist.
HTTP/0.9 stellt ein gutes Beispiel für eine typischen Fehler bei der Spezifikation von Protokollen dar:
Für ein Protokoll, das in einem globalen Netzwerk eingesetzt werden soll, ist die Spezifikation viel zu
spezifisch. Es werden unnötig strenge Annahmen über das Format der Anfragen wie auch das Format der
Dokumente getroffen, die Spezifikation schließt jegliche Erweiterungen a priori aus. Schließlich ist es auch
nicht möglich, dem Server weitergehende Informationen über den Client oder dessen Wünsche mitzuteilen, was sich
bald als größter Nachteil erweisen sollte.
Als folgenreicher, weil schwerer zu beheben und in seinen Konsequenzen lang nicht klar erkannt, hat sich jedoch die
Entscheidung erwiesen, zur Kennzeichnung des Endes eines Dokumentes das Ende der TCP-Verbindung zu benützen. Damit
muß für jede Anfrage von einem Client A an einen Server B eine neue TCP-Verbindung aufgebaut werden,
auch wenn A wiederholt Anfragen an B stellt. Leider wird aber gerade dieser Fall nach dem Prinzip der
Lokalität häufig vorkommen. Dies hat zu einer merklich höheren Last im Netz wie auf den HTTP-Servern geführt und
wird erst in jüngster Zeit kompensiert (vgl. Abschnitt 3.1).
Eine wichtige, aber bis heute gültige Einschränkung von HTTP, die sich im Gegensatz zu den übrigen als sehr segensreich erwiesen hat, da sie die Implementation und Wartung von Webservern deutlich erleichtert, ist schließlich das Fehlen von Zustandsinformationen. Eine HTTP-Anfrage besitzt keinen Zustand, ein Web-Server »weiß« nichts von vorhergehenden Anfragen eines Clients und soll eine Anfrage immer in der gleichen Weise behandeln. Offensichtlich vereinfacht dies die Operationen mittels HTTP beträchtlich. Auch diese Einschränkung wird jedoch kontrovers diskutiert und ist bereits z.T. durch die Einführung von Cookies aufgehoben worden, die jedoch nicht zum offiziellen Standard gehören (vgl. [RFC 2109]).
In einem globalen Netzwerk ist eine Methode zur konsistenten und eindeutigen Benennung und Adressierung von Ressourcen entscheidend, da sonst Ressourcen nicht zwischen verschiedenen Nutzern ausgetauscht und übergreifend genutzt werden können. Im Internet (bzw. dessen Vorgänger ArpaNet) ist ursprünglich ausschließlich die Adresse einer Ressource als deren Identifikator benutzt worden: URL, Uniform Resource Locator. Jede referenzierbare Ressource muß also an einer eindeutigen und (möglichst) unveränderlichen Adresse zu finden sein.
Eine URL ist im wesentlichen (es gibt einige weitere, aber recht seltene Varianten, insbesondere mit
?
-Query-Indikator) wie folgt aufgebaut:
Das Schema bezeichnet ein definiertes Schema für URLs, wie z.B. http
, wobei jeder
beliebige String als Schema gültig ist, anders als die üblichen URLs, in denen stets ein Protokoll-Name als
Schema-Name verwendet wird, scheinbar implizieren. Durch das Schema wird die Syntax der übrigen URL (als Pfad
bezeichnet) spezifiziert
(z.B. muß im HTTP-Schema stets //
auf das Schema und den Schema-Indikator :
folgen),
nur die Bedeutung von /
(hierarchisches Trennzeichen) und #
(Fragment-Indikator) ist
fest vorgegeben.
So sind beispielsweise die folgenden Strings gültige URLs:
ftp://ftp.is.co.za/rfc/rfc1808.txtDieses Schema hat seine Vorteile, insbesondere seine Einfachheit und die Unabhängigkeit von zentralen Namensdatenbanken für die Ressourcen, auch wenn viele Schemas (z.B. HTTP) einen Zugriff auf Namensdatenbanken für Hosts (DNS) zur Auflösung der Ressource benötigen, hier wird aber auch nur der Hostname erfragt, während die eigentliche Ressourcen-Auflösung durch diesen Host erfolgt.
Trotz dieser Vorteile hat dieses Schema, soviel es dank seiner Einfachheit auch zur raschen Verbreitung des Internets beigetragen hat, gravierende Nachteile für Ressourcen deren Adresse nicht fixiert sein soll oder kann. Mit dem Ziel, von Adressen unabhängige Ressourcen-Identifikatoren zu ermöglichen, ist die URL-Syntax erweitert worden zu den sogenannten URIs:
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. [RFC 2396]
URIs werden offensichtlich durch die drei folgenden Eigenschaften charakterisiert:
/
als
hierarchischer Indikator)
The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. Thus, a resource can remain constant even when its content — the entities to which it currently corresponds — changes over time, provided that the conceptual mapping is not changed in the process. [RFC 2396]
Die Syntax für URIs sieht ebenfalls eine Trennung der URI in Schema und Pfad vor. Es gibt zwei Haupttypen von URIs, dies sind eben URLs und URNs:
URIs which refer to objects accessed with existing protocols are known as Uniform Resource Locators (URLs). [RFC 2396]
Diese Definition ist leider nicht ganz zureichend, genauer ist eine URL diejenige Teilmenge der URIs, die Ressourcen mitttels der Repräsentation ihres hauptsächlichen Zugriffsmechanismus und nicht über Namen oder andere Attribute der Ressource identifiziert.
There is currently a drive to define a space of more persistent names than any URLs. These Uniform Resource Names are the subject of an IETF working group's discussions. [RFC 2396]
Kurz gesagt sind also URLs die traditionelle Form der URIs, während URNs einen Mechanismus zur Verfügung stellen sollen, um Ressourcen unabhängig von ihrer Adresse global eindeutig zu identifizieren und dauerhaft zu halten, auch wenn die Ressource auf keine Entität mehr zeigt oder die Entitäten nicht verfügbar sind. Angesichts der Anzahl an »toten« Links und Weiterleitungen an neue Adressen (vgl. Abschnitt 4) ist die Bedeutung eines solchen Mechanismus ausgesprochen hoch. Es ist jedoch noch nicht klar, wie eine Abbildung zwischen URNs und realen Adressen aussehen soll.
Eine URN unterscheidet sich also von einer URL dadurch, daß ihr wesentlicher Zweck die dauerhafte Benennung
einer Ressource mit einem Bezeichner ist. Dieser Bezeichner wird aus einem der definierten Namensräume
ausgewählt,
von denen jeder seine eigene Namensstruktur definiert. Das »urn
«-Schema ist reserviert
für einen standardisierten URN-Namensraum.
Das http
-Schema wird verwendet, um Ressourcen im Netzwerk über das HTTP-Protokoll zu
lokalisieren. Die schemaspezifische Syntax ist:
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Dabei wird Port 80 als Standardport verwendet. Die Semantik ist, daß die identifizierte Ressource auf
dem Server liegt, der TCP-Verbindungen an dem gegeben Port auf dem gegebenen Host annimmt, und daß
die Anfrage-URI für die Ressource der abs_path
-Anteil ist. IP-Adressen sollen vermieden
werden. Ist der absolute Pfad leer, so muß /
als Request-URI verwendet werden. Fragmentindikator
und -identifikator werden ebenfalls nicht Teil der Anfrage-URI, sondern durch den Client ausgewertet.
All diese Einschränkungen legen eigentlich nahe, daß die Anpassung des Standards zur Unterstützung der fehlenden Möglichkeiten rasch geschehen hätte sollen. So hat Berners-Lee selbst schon 1992 ein Dokument vorgelegt, in dem er die Anforderungen an ein »richtiges« Transfer-Protokoll für das WWW vorgelegt hat. Zentrale Idee dabei war es, daß nicht nur Hypertext, sondern Hypermedia-Dokumente, also Dokumente in allen denkbaren Datenformaten, übertragen werden können. Um dies zu ermöglichen, muß jedoch das Protokoll eine Möglichkeit bereitstellen, daß (1) der Client anzeigen kann, welche Datenformate er verarbeiten kann, und (2) der Server die übertragenen Daten mit Metainformationen z.B. über das Format anreichern kann.
Tatsächlich dauerte jedoch die Entwicklung dieses neuen Protokolls (das so wenig mit dem alten HTTP/0.9 gemein hatte, daß man die Unterstützung von Anfragen im alten Format explizit als Kompatibilitätsmodus fordern mußte) über vier Jahre und wurde erst im Mai 1996 durch die IETF (Internet Engineering Task Force), allerdings nur als Informational RFC ([RFC 1945]) fixiert — also nicht als echter Standard, sondern nur zur Beschreibung der empfehlenswerten (und üblichen) Nutzung von HTTP, in dieser Hinsicht vergleichbar zu HTML 3.2. Einer der Gründe, daß man sich scheute ein normatives RFC (Request for Comment, entspricht etwa einer Recommendation des W3C, allerdings in erster Linie für die eher technischen Seiten des Internets verwendet) zu publizieren, war die andauernde Unzufriedenheit über die Realisierung von HTTP. Diese wurde erst durch HTTP/1.1 teilweise beseitigt.
Um die Änderungen gegenüber HTTP/0.9 vorzustellen, sei eine Beispielsitzung gezeigt, die ebenfalls die
GET
-Methode verwendet:
tim@orodreth:~ > telnet jigsaw.w3.org 80 Trying 138.96.249.65... Connected to jigsaw.w3.org. Escape character is '^]'. GET / HTTP/1.0 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT HTTP/1.1 200 OK Date: Sun, 16 Jul 2000 11:27:11 GMT Content-Length: 4097 Content-Location: http://jigsaw.w3.org:80/Overview.html Content-Type: text/html;charset=ISO-8859-1 Etag: "mvanct:s0m02tu0" Last-Modified: Wed, 05 Jul 2000 15:32:00 GMT Server: Jigsaw/2.1.0 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <HTML> <HEAD> <TITLE>Jigsaw Overview</TITLE> <!-- Changed by: Benoit Mahe, 29-Apr-1998 --> <!-- Changed by: Yves Lafon, 25-Mar-1999 --> <!-- Changed by: Benoit Mahe, 6-May-1999 --> <STYLE TYPE="text/css"> [...] </HTML> Connection closed by foreign host.
Die beiden auffälligsten Änderungen sind die Versionsnummer in der Anfrage und die vom Server gesendeten Informationen vor dem Dokument. Was also sind nun die wesentlichen Neuerungen in HTTP/1.0?
Is-Modified-Since
ergänzt werden.
Eine Ressource wird dann nur übertragen, wenn sie seit dem angegebenen Datum verändert worden ist.
Accept
angeben, welche Datenformate er für die angeforderte Ressource vorziehen würde.
Die Reaktion des Servers, falls die Ressource in keinem der angegebenen Datenformate vorliegt, ist im Standard
nicht spezifiziert. Üblicherweise wird die
Ressource in einem der auf dem Server
vorhandenen oder erzeugbaren Formate übertragen, da der Standard
keinen Fehlercode (s.u.) für diesen Fall vorsieht.
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. [RFC 1945]
HEAD
-Methode, wie in der
folgenden Beispielsitzung dargestellt (es wird die gleiche Ressource wie in der letzten Sitzung angefragt):
tim@orodreth:~ > telnet jigsaw.w3.org 80 Trying 138.96.249.65... Connected to jigsaw.w3.org. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 16 Jul 2000 11:28:41 GMT Content-Length: 4097 Content-Location: http://jigsaw.w3.org:80/Overview.html Content-Type: text/html;charset=ISO-8859-1 Etag: "mvanct:s0m02tu0" Last-Modified: Wed, 05 Jul 2000 15:32:00 GMT Server: Jigsaw/2.1.0 Connection closed by foreign host.
POST
-Methode erlaubt es dem Client größere Mengen an Daten
an den Server zur Verarbeitung zu senden. Bisher waren solche Informationen in der URL übertragen worden (nach
dem Query-Indikator ?
), wodurch der Aufwand für das Parsing der URL wächst, Leerzeichen,
Zeilenumbrüche und andere in URLs nicht zugelassene Zeichen maskiert werden müssen. Dadurch ist
es nun möglich gewesen Formulare, Studien etc. im WWW zu veröffentlichen und zu verarbeiten.
tim@orodreth:~ > telnet jigsaw.w3.org 80 Trying 138.96.249.65... Connected to jigsaw.w3.org. Escape character is '^]'. DELETE / HTTP/1.0 HTTP/1.1 405 Method Not Allowed Date: Sun, 16 Jul 2000 11:29:23 GMT Content-Length: 26 Content-Type: text/html Server: Jigsaw/2.1.0 Method DELETE not allowed.Connection closed by foreign host.
200 ok
) oder ob und welcher Fehler aufgetreten ist.
Dadurch ist es dem Client u.U. möglich geeignete Maßnahmen zu ergreifen oder wenigstens dem Nutzer eine
sinnvolle Fehlermeldung (wie das berüchtigte 404 Not Found
) zu liefern. 403
Forbidden
generiert, wie die folgende Sitzung zeigt:
tim@orodreth:~ > telnet www.pms.informatik.uni-muenchen.de 80 Trying 129.187.214.81... Connected to www.pms.informatik.uni-muenchen.de. Escape character is '^]'. GET /studinfo/ HTTP/1.0 HTTP/1.1 403 Forbidden Date: Sun, 16 Jul 2000 11:30:34 GMT Server: Apache/1.3.6 (Unix) (SuSE/Linux) mod_ssl/2.3.11 OpenS SL/0.9.3 PHP/3.0.11 mod_perl/1.19 Content-Location: forbidden.de.shtml Vary: negotiate, accept-language TCN: choice Connection: close Content-Type: text/html Content-Language: de Expires: Sun, 16 Jul 2000 11:30:34 GMT <HTML> <HEAD> <TITLE>Error 403!</TITLE> <!-- Changed by: Lars Eilebrecht --> [...]
Diese Erweiterungen sind heute der Kern von HTTP und haben den ungeheuren Erfolg des Internets als Hypermedia-System erst ermöglicht:
This Hypertext Transfer Protocol (HTTP) made it very easy for any computer on the Internet to safely offer up its collection of documents into the greater whole; using HTTP, a computer that asked for a file from another computer would know, when it received the file, if it was a picture, a movie, or a spoken word. With this feature of HTTP, the Internet began to reflect an important truth—retrieving a file's data is almost useless unless you know what kind of data it is. In a sea of Web documents, it's impossible to know in advance what a document is—it could be almost anything—but the Web understands »data types« and passes that information along.
Mark Pesce, 1995.
Neben den unbestreitbaren Vorzügen dieser
Erweiterungen haben diese jedoch auch unzählige Probleme mit sich
gebracht (eben da es sich nicht um durchdachte Lösungen, sondern um eine Beschreibung der vorhandenen, z.T.
nur mit Aussicht auf schnellen kommerziellen Erfolg entwickelten Ansätze handelt). Insbesondere haben diese
Erweiterungen zu einer Explosion des Netzverkehrs geführt, da erstens aufwendigere (Bild-) Daten übertragen werden
und zweitens für die Darstellung einer Seite durch Browser (und andere Endnutzer-Anwendungen), die nur zum Ziel
haben, die Seiten möglichst schnell darzustellen, häufig mehrere parallele Verbindungen zu dem Origin Server einer
Ressource geöffnet werden (z.B. für die Teile einer Frame-Seite oder für Bilder), wodurch nicht nur
deutlich mehr Bandbreite verbraucht wird, sondern auch die Server drastisch stärker belastet werden.
Schließlich haben sich durch das Wachstum des Internets die technischen Probleme von HTTP/1.0 noch verschärft, so
daß die HTTP-Arbeitsgruppe der IETF bereits 1995 die Arbeit an einem echten Standard, der einen Großteil der
Probleme entschärfen sollte, aufgenommen hatte. Diese Entwicklung hat schließlich bereits 1997 in HTTP/1.1
geendet.
The Internet is suffering from the effects of the HTTP/1.0 protocol, which was designed without thorough understanding of the underlying TCP transport protocol. [WD MUX]
Wie bereits mehrfach angedeutet, hat sich die Entscheidung, für jede HTTP-Anfrage eine neue TCP-Verbindung zwischen Client und Server aufzubauen, als problematisch für die Geschwindigkeit erwiesen. Man bezeichnet ein derartiges Protokoll als verbindungslos (connectionless). Diese Technik (für jede Transaktion eine neue Verbindung aufzubauen) hat sich bei einige Anwendungen als durchaus segensreich erwiesen, allerdings nur wenn das verwendete Transportprotokoll dafür geeignet ist. Dies gilt für TCP nun leider nicht, hauptsächlich aus zwei Gründen:
Beide Probleme haben entscheidend zur Unzufriedenheit mit HTTP/1.0 beigetragen und es ist versucht worden, sie in HTTP/1.1 zu entschärfen.
Nach dieser kurzen Motivation soll nun ein Überblick über die Neuerungen von HTTP/1.1 (angelehnt an [Kris 1998]) gegeben werden.
Wie in Abschnitt Ex. 1 dargestellt, treten bei der Nutzung von HTTP/1.0 über
TCP durch den Aufbau einer Verbindung pro Anfrage erhebliche Probleme auf. Einige Implementationen von HTTP
haben versucht, durch Verwendung des Keep-Alive
-Headerfeldes, das anzeigen soll, daß eine
Verbindung offengehalten werden soll, diese Probleme zu behandeln. Jedoch ist dies von Mittlern wie Proxies und
Gateways nicht beachtet worden, so daß man bei der Entwicklung von HTTP/1.1 einen umfassenden Lösungsansatz
entwickelt hat: Persistente Verbindungen (persistent connections).
Es wird also eine einzige Verbindung für alle Anfragen eines Clients an einen Server verwendet. Die Vorteile sind
offensichtlich:
Durch persistente Verbindungen allein kann jedoch die Frage, wie eine Web-Seite mit eingebetteten Ressourcen wie
Bildern effizient behandelt werden kann, nicht gelöst werden. Wie bereits bemerkt, öffnen die gängigen User
Agents (Web-Browser) dazu mehrere parallele Verbindungen mit entsprechend ansteigendem Overhead, besonders
falls bereits eine Stauung im Netz vorliegt. HTTP/1.1 bietet hierfür wiederum einen angemesseneren, wenn auch
komplexeren Ansatz: Pipelining von HTTP-Nachrichten.
Ein Client kann nun eine weitere Anfrage stellen, ohne auf die Antworten auf vorherige Anfragen warten zu müssen.
Der Server muß jedoch die Anfragen in der richtigen Reihenfolge abarbeiten und die Antworten entsprechend
generieren. Dies ist nur möglich, da TCP garantiert, daß Daten in der korrekten Reihenfolge übermittelt werden.
Der Client kann beliebig viele Anfragen senden, ohne eine Antwort zu erhalten, es wird hier keine
Overflow-Behandlung definiert.
Offensichtlich tritt bei dieser Vorgehensweise ein Problem auf (allerdings auch bei mehreren parallelen
Verbindungen): HTTP-Anfragen können Seiteneffekte haben, die dazu führen, daß darauf folgende Anfragen zu
anderen Ergebnissen führen.
Angenommen eine Anfrage A füge (z.B. mittels POST
) eine Ware in einen Warenkorb eines
E-Shops ein, eine Anfrage B gebe den Inhalt des Warenkorbs aus. Offensichtlich kann die Ausführung
von A und B in einer Pipeline zu einem falschen Ergebnis führen (Hazard). Das Protokoll
überläßt es vollständig dem Client, dafür zu sorgen, daß solche Anfragen nicht gepipelined werden. Dies
dürfte einer der Gründe sein, daß aktuelle User Agents (wie z.B. alle verbreiteten Browser) kein Pipelining
für Anfragen verwenden, da es nicht klar ist, wie ein Client solche Abhängigkeiten erkennen kann. Leider ist
nach dem HTTP-Standard weder die Implementation von persistenten Verbindungen noch von Pipelining
Pflicht, beide sind nur empfohlen. Diese Entscheidung bedingt, daß einem Client, der keine persistenten
Verbindungen implementiert, eine Möglichkeit gegeben wird, dies dem Server anzuzeigen: Dazu dient das
Connection
-Feld im Request-Header, wie in der folgenden Sitzung dargestellt, welches nur die Werte
close
(schließe die Verbindung sofort wieder) oder default
annehmen kann
GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/plain Connection: close HTTP/1.1 200 OK [...] foo text Connection closed by foreign host.
Die Quantifizierung des Nutzens vor allem von persistenten Verbindungen ist in der Forschung immer noch heftig umstritten:
Our analysis indicates that the persistent connection optimizations do not substantially affect Web access for the vast majority of users. Most users see end-to-end latencies of about 250 ms and use modem lines. At these rates, the optimizations reduce the overall transaction time by 11%. Bandwidths over 200 Kbps are required to provide user-noticeable performance improvements. [Heid 1996]
Our study has shown that on a wireless network, HTTP/1.1 doubles the throughput of HTTP/1.0, while reducing the number of packets sent by 60%. We believe this significantly improves the performance seen by the user and increases the scalability of the wireless network. In the future, wide area wirless networks are likely to remain high latency because of the inherent interference wireless networks must overcome. In addition, for these wireless networks to remain inexpensive, there will have to be many wireless routers without a wired connection to the Internet, thus causing packets to traverse several high latency wireless hops. Similarly, satellite-based wireless networks are likely to have high latency. However, these wireless networks will have greatly increased bandwidth because of more eficient use of the spectrum and the allocation of more parts of the spectrum. In such an environment, we believe that HTTP/1.1 will have even greater benefits than we have measured. [Cheng 1999]
Trotzdem unterstützen mittlerweile alle verbreiteten Clients (Browser, Proxies) und Server persistente Verbindungen, während Pipelining zwar auf Seiten der Server und Mittler unterstützt wird, durch die gängigen User Agents jedoch kaum genutzt wird, da hier erheblicher Implementationsaufwand erforderlich wäre. So baut Netscapes Navigator immer noch bis zu 6 parallele Verbindungen zu einem Server für eine Seite auf, Microsofts Internet Explorer immerhin bis zu 2.
Schon früh ist deutlich geworden, daß ein effizientes Caching einen großen Beitrag zur Verringerung der Antwortzeiten und der Netzlast beitragen kann. Effizientes Caching setzt jedoch eine umfassende Kenntnis der zu cachenden Ressource voraus, da nur so verläßlich entschieden werden kann, was wie lange gecached werden darf. Eine solche Kenntnis besitzt i.a. nur der Origin Server einer Ressource, daher ist es für effizientes Caching nötig, daß der Origin Server volle Kontrolle über das Caching seiner Ressourcen erhält.
HTTP/1.1 fügt der einfachen und z.T. undurchdachten Unterstützung von Caches in HTTP/1.0 eine ansehnliche Anzahl weiterer Steuerungsmöglichkeiten hinzu, so daß heutige Proxy-Caches eine Trefferrate von 20-40% erreichen (was nahe an der oberen Grenze von 30-50% liegt, vgl. [Abra 1995]
Ein Problem der bisher verwendeten Caching-Methoden ist die Verwendung von absoluten Zeitstempeln (z.B.
im
If-Modified-Since
- oder Expires
-Headerfeld), die in einem globalen Netz (aufgrund
von Verzögerung, fehlender Synchronisation etc.) zu semantisch intransparentem Verhalten des Caches führen
können. Daher verwendet HTTP/1.1 zum einen relative Zeitangaben (max-age
), zum anderen einen
neuen Mechanismus zur Revalidierung einer Ressource: Jeder Entität wird ein Etag
oder Entity-Tag
durch den Origin Server zugeordnet (dieses muß eindeutig sein). Zur Revalidierung sendet der Cache eine
bedingte Anfrage mit If-Match
-Feld, wie in der folgenden Sitzung:
GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/plain If-Match: "asd" HTTP/1.1 412 Precondition Failed Date: Fri, 21 Jul 2000 17:33:20 GMT Content-Length: 22 Content-Location: http://jigsaw.w3.org/HTTP/neg.txt Content-Type: text/html Server: Jigsaw/2.1.0 Vary: Accept GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/plain If-Match: "1tgurff:q71vpin8" HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:34:22 GMT Content-Length: 9 Content-Location: http://jigsaw.w3.org/HTTP/neg.txt Content-Type: text/plain Etag: "1tgurff:q71vpin8" Expires: Sun, 23 Jul 2000 17:34:22 GMT Last-Modified: Tue, 20 Jun 2000 22:49:36 GMT Server: Jigsaw/2.1.0 Vary: Accept foo text GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/plain If-Modified-Since: Tue, 20 Jun 2000 22:50:30 GMT HTTP/1.1 304 Not Modified Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:35:45 GMT Content-Location: http://jigsaw.w3.org/HTTP/neg.txt Etag: "1tgurff:q71vpin8" Expires: Sun, 23 Jul 2000 17:35:45 GMT Server: Jigsaw/2.1.0 Vary: Accept GET /HTTP/cc-private.html HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 200 OK Cache-Control: private Date: Tue, 18 Jul 2000 11:38:00 GMT Content-Length: 834 Content-Language: en Content-Type: text/html Etag: "1127irf:q0efehi8" Expires: Thu, 20 Jul 2000 11:38:00 GMT Last-Modified: Tue, 20 Jun 2000 22:47:33 GMT Server: Jigsaw/2.1.0
Die meisten übrigen Erweiterungen (wie der Cache-Control
-Header) erlauben dem Origin Server genau
zu spezifizieren, ob, wie lange, für wen etc. eine Antwort vorgehalten werden darf. Generell gilt, daß nur
Antworten auf GET
- und HEAD
-Anfragen gecached werden dürfen, außer der Origin Server
erlaubt explizit Caching.
Zur genauen Bedeutung der verschiedenen Headerfelder zur Steuerung eines Caches vergleiche man
[RFC 2616] bzw. [Stal 2000].
Auch wenn es scheinen mag, daß die Komplexität der Caches durch diese Erweiterung deutlich anwächst, ist dies nicht der Fall. Indem die Kontrolle über das Cacheverhalten bezüglich einer Ressource durch den Origin Server übernommen wird, werden die Caches sogar entlastet. Dies ist besonders bei Proxy-Caches von großem Vorteil. Schließlich können nun auch Anfragen mit Nebeneffekten, die bisher häufig zu semantischer Intransparenz geführt haben, korrekt behandelt werden.
Ein zentrales Ziel bei der Entwicklung von HTTP/1.1 resultiert aus den bitteren Erfahrungen mit verschiedenen nur teilweise kompatiblen Versionen von HTTP/1.0, die immer wieder zu erheblichen Problemen geführt hatten. Um diese Probleme künftig so weit wie möglich zu umgehen und gleichzeitig die Entwicklung von Erweiterungen zu erleichtern, legt HTTP/1.1 großen Wert auf Erweiterbarkeit.
Wie schon bei HTTP/1.0 ist es möglich, die Header-Felder zu erweitern, ohne dadurch bestehende HTTP-Anwendungen
zu beeinträchtigen, da diese unbekannte Header-Felder ignorieren dürfen. Gleichzeitig wird nun eine
Möglichkeit gegeben auch weitere Methoden hinzuzufügen. Dazu gibt es eine neue Methode OPTIONS
, die
Auskunft über die unterstützen Methoden einer Ressource (OPTIONS URI
) oder eines Servers
(OPTIONS *
) gibt:
OPTIONS * HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 200 OK Date: Fri, 21 Jul 2000 17:25:13 GMT Public: GET,HEAD,PUT,POST,LINK,UNLINK,DELETE,OPTIONS,TRACE Server: Jigsaw/2.1.0 OPTIONS /HTTP/TE/foo.txt HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:25:37 GMT Allow: GET,HEAD,OPTIONS,TRACE Etag: "1pe1kjm:q7kclme8" Expires: Sun, 23 Jul 2000 17:25:37 GMT Last-Modified: Mon, 26 Jun 2000 00:03:37 GMT Server: Jigsaw/2.1.0
Das gerade gegeben Beispiel zeigt auch, daß selbst der vom W3C entwickelte Jigsaw-HTTP-Server die
RFC 2616 nicht korrekt umsetzt: Das Headerfeld Public
darf nicht länger verwendet werden und es
gilt für die Antwort auf eine OPTIONS
-Methode: »If no response body is included, the
response MUST include a Content-Length field with a field-value of "0".«
[RFC 2616]
Von einem echt erweiterbaren Protokoll ist HTTP jedoch noch weit entfernt, dies wird als ein bedeutsamer Nachteil angesehen und soll in kommenden Versionen korregiert werden (vgl. Abschnitt 4).
HTTP/1.0 verschwendet in vieler Hinsicht Bandbreite im Netzwerk, nicht nur durch die ineffiziente Nutzung von
TCP (vgl. Abschnitt Ex. 2): Zum einen wird eine Ressource stets komplett an den Client übertragen, auch wenn
dieser nur einen Teil davon benötigt. Umgekehrt wird eine große Anfrage (z.B. eine PUT
- oder
POST
-Operation) stets komplett übertragen, auch wenn der Server diese nicht verarbeiten kann.
Beide Probleme werden in HTTP/1.1 angegangen.
Wenn ein Client nur einen Teil einer Ressource benötigt (z.B. nur den Beginn eines Dokuments), erlaubt
HTTP/1.1 ihm dies durch sogenannte Bereichsanfragen (range requests): Mit Hilfe des
Range
-Headerfelds spezifiziert der Client den Bereich der Ressource, an dem er interessiert ist. Dieser
Mechanismus ist zwar auf beliebige Einheiten erweiterbar (z.B. Kapitel eines Dokuments), jedoch in HTTP/1.1
nur für Bytes realisiert, da über andere Einheiten keine Einigung erziehlt werden konnte (u.a. da es nicht
klar ist, wie andere Einheiten definiert werden sollen, vgl. Abschnitt 4).
Bereichsanfragen für Bytes können auf unterschiedliche Weise verwendet werden, z.B. um
Dies ist wiederum eine Fähigkeit von HTTP/1.1, die nicht implementiert werden muß, aber empfohlen wird.
Die folgende Beispielsitzung zeigt die Verwendung des Range
-Feldes und die Antwort eines
Servers auf diese Anfrage (mit 206 Partial Content
), wobei die erste Anfrage die letzten 20,
die zweite die ersten 200 Bytes derselben Ressource anfordert:
GET / HTTP/1.1 Host: jigsaw.w3.org Range: bytes=-20 HTTP/1.1 206 Partial Content Date: Sun, 16 Jul 2000 22:49:26 GMT Content-Length: 20 Content-Location: http://jigsaw.w3.org/Overview.html Content-Range: bytes 4077-4096/4097 Content-Type: text/html;charset=ISO-8859-1 Etag: "mvanct:s0m02tu0" Last-Modified: Wed, 05 Jul 2000 15:32:00 GMT Server: Jigsaw/2.1.0 --> </BODY></HTML> GET / HTTP/1.1 Host: jigsaw.w3.org Range: bytes=0-200 HTTP/1.1 206 Partial Content Date: Sun, 16 Jul 2000 22:52:47 GMT Content-Length: 201 Content-Location: http://jigsaw.w3.org/Overview.html Content-Range: bytes 0-200/4097 Content-Type: text/html;charset=ISO-8859-1 Etag: "mvanct:s0m02tu0" Last-Modified: Wed, 05 Jul 2000 15:32:00 GMT Server: Jigsaw/2.1.0 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <HTML> <HEAD> <TITLE>Jigsaw Overview</TITLE> <!-- Changed by: Benoit Mahe, 29-Apr-1998 --> <
Es wäre wünschenswert, daß bei der Anforderung einer URI, die einen Fragmentindikator (#
)
enthält, nur dieses
Fragment übertragen wird und nicht die gesamte Ressource. Dies ist jedoch in HTTP/1.1 nicht möglich, vielmehr
spezifiziert das Protokoll, daß eine URI tatsächlich ohne Fragmentindikator und Fragmentidentifikator an den
Server gesendet, die gesamte Ressource zum Client übertragen wird und schließlich der Client den
Fragmentidentifikator auswertet. Diese Vorgehensweise wird durch die Realisierung von Fragmenten in HTML
erzwungen (es ist nicht klar, wie weit ein Fragment reicht, da nur sein Beginn über einen Anker definiert
ist). Es besteht jedoch die Hoffnung, daß es durch Techniken im Umfeld von XML (XPointer) möglich wird,
tatsächlich nur die erwünschten Fragmente zu übertragen (vgl. Abschnitt 4).
Umgekehrt erfordern einige HTTP-Anfragen (wie z.B. die PUT
- oder POST
-Methode)
Anfragerümpfe beliebiger Länge. Wenn der Server eine solche Anfrage nun ablehnt, z.B. aufgrund
eines
Authentifikations-Fehlers, wird eine nennenswerte Menge Bandbreite für die Übertragung des großen
Anfragerumpfs verschwendet.
Dies wird vermieden, indem der Client das Feld Expect: 100-continue
zu seiner Anfrage hinzufügt, und
der Server darauf entweder mit einer Fehlermeldung (falls die Anfrage nicht verarbeitet werden kann) oder mit
100 Continue
antwortet, was der Client wiederum mit dem eigentlichen Anfragerumpf
beantwortet.
Schließlich bietet HTTP/1.1 endlich eine sinnvolle Möglichkeit, Bandbreite durch Kompression der zu übertragenden Daten zu reduzieren. Es ist gezeigt worden, daß sich durch aggressiven Einsatz von Kompression 40% der mittels HTTP übertragenen Daten einsparen lassen. HTTP/1.1 unterscheidet zwischen
Diese Unterscheidung ist sinnvoll, da es so möglich ist, auf verschiedenen Teilstrecken unterschiedliche Codierungen zu verwenden, z.B. wenn ein beteiligter Client nur identische Codierung unterstützt.
Während bereits HTTP/1.0 eine Möglichkeit die Codierung einer Ressource anzugeben
(Content-Encoding
Header) bot, ist erst durch HTTP/1.1 dieser Mechnismus
effektiv nutzbar, da es ermöglich wird (über das Accept-Encoding
-Feld im Anfrage-Header) die durch
den User Agent unterstützen Codierungen anzugeben. Analoge Möglichkeiten gibt es auch für das Transfer-Encoding.
Die folgende Sitzung illustriert verschiedene Transfer-Encodings (gzip, deflate, Identität) für dieselbe Ressource. Da beide verwendeten Kompressionsverfahren adaptiv sind und die Ressource sehr repetitiv ist, ist auch der Gewinn durch die Kompression sehr hoch:
GET /HTTP/TE/foo.txt HTTP/1.1 Host: jigsaw.w3.org TE: gzip HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:21:30 GMT Transfer-Encoding: gzip,chunked Content-Type: text/plain Etag: "1pe1kjm:q7kclme8" Expires: Sun, 23 Jul 2000 17:21:30 GMT Last-Modified: Mon, 26 Jun 2000 00:03:37 GMT Server: Jigsaw/2.1.0 54 d!Îç_©V5_Eßé_"""""""""""""""""""""""""""""""""""ò+ 0¿+¸ kÔÖ H 0 GET /HTTP/TE/foo.txt HTTP/1.1 Host: jigsaw.w3.org TE: deflate HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:23:22 GMT Transfer-Encoding: deflate,chunked Content-Type: text/plain Etag: "1pe1kjm:q7kclme8" Expires: Sun, 23 Jul 2000 17:23:22 GMT Last-Modified: Mon, 26 Jun 2000 00:03:37 GMT Server: Jigsaw/2.1.0 2 x 46 d!Îç_©V5_Eßé_"""""""""""""""""""""""""""""""""""ò+ 0¿+¸ ]w x 0 GET /HTTP/TE/foo.txt HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Fri, 21 Jul 2000 17:24:00 GMT Content-Length: 18432 Content-Type: text/plain Etag: "1pe1kjm:q7kclme8" Expires: Sun, 23 Jul 2000 17:24:00 GMT Last-Modified: Mon, 26 Jun 2000 00:03:37 GMT Server: Jigsaw/2.1.0 big text big text big text big text [noch 1000mal "big text"]
HTTP-Nachrichten können einen Rumpf beliebiger Länge enthalten, so daß ein Mechanismus definiert werden muß,
um das Ende einer Nachricht zu bestimmmen. HTTP/1.0 stellt dafür den Content-Length
Header zur
Verfügung, der die Länge des Nachrichtenrumpfes enthält. Dazu muß aber offensichtlich die Länge der Entität
bereits im voraus bekannt sein, was bei dynamisch generierten Entitäten nicht der Fall ist. Bisher mußten
solche Entitäten vollständig generiert und gepuffert werden, um ihre Länge zu berechnen und konnten erst
dann verschickt werden, wodurch die Antwortzeit (bei großen Antworten deutlich) anwächst. Bei HTTP/1.0
ist dies noch kein bedenkliches Problem gewesen, da der Content-Length
Header nicht notwendig
gewesen ist, das Ende der Nachricht ist ja durch das Schließen der Verbindung markiert worden. In HTTP/1.1 ist
dies nicht mehr sinnvoll, daher ist eine bessere Möglichkeit entwickelt worden, die fragmentierte
Transferkodierung (Chunked Transfer-Encoding):
Der Sender zerlegt die Nachricht in Fragmente beliebiger Länge, die mit ihrer Länge verschickt werden, wobei ein
leeres Fragment das Ende der Nachricht bezeichnet (vgl. Abbildung 9). Der Sender markiert eine fragmentierte
Nachricht durch den Header Transfer-Encoding: chunked
.
Dadurch kann der Sender jeweils nur kleine Teile der Nachricht puffern, ohne daß merklich Komplexität oder
Overhead hinzugefügt wird. Aufgrund der Einfachheit dieser Lösung müssen alle HTTP/1.1-Implementationen dieses
Verfahren unterstützen.
Die folgende Beispielsitzung zeigt eine Antwort in fragmentierter Transfer-Kodierung, wobei das erste Fragment die Größe 789 besitzt:
GET /HTTP/ChunkedScript HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 200 OK Date: Tue, 18 Jul 2000 11:21:39 GMT Transfer-Encoding: chunked Content-Type: text/plain Etag: W/"b2vd8d:q0efehi8" Last-Modified: Tue, 20 Jun 2000 13:38:26 GMT Server: Jigsaw/2.1.0 789 This output will be chunked encoded by the server, if your client is HTTP/1.1 Below this line, is 1000 repeated lines of 0-9. ------------------------------------------------------------------------- 01234567890123456789012345678901234567890123456789012345678901234567890 01234567890123456789012345678901234567890123456789012345678901234567890
Ein Beispiel für die Verwendung von fragmentierten Nachrichten ist die Antwort auf die neue Methode
TRACE
, die einfach die Anfrage als Antwortrumpf wieder zurückgibt:
TRACE / HTTP/1.1 Accept: Schokolade/Essen Host: localhost HTTP/1.1 200 OK Date: Tue, 25 Jul 2000 13:47:15 GMT Server: Apache/1.3.12 (Unix) (SuSE/Linux) ApacheJServ/1.1 Transfer-Encoding: chunked Content-Type: message/http 3f TRACE / HTTP/1.1 Accept: Schokolade/Essen Host: localhost 0
Einige HTTP-Headerfelder (z.B. ETag
) erfordern die Kenntnis des Inhalts der gesamten Nachricht.
Um dafür wieder nicht die ganze Nachricht puffern zu müssen, führt HTTP/1.1 bei fragmentierten Nachrichten
einen Trailer ein, in dem solche Felder übertragen werden können, wobei im Header ein Verweis auf die
Trailer-Felder existieren muß.
Mit dem Anwachsen des Internets wächst auch die Anzahl an Hostnamen (wie www.w3.org
) dramatisch
an. Die Anzahl an Hostnamen ist unbegrenzt, nicht jedoch die Anzahl an IP-Adressen. Daher erlaubt das
Domain Name System (DNS) mehrere Hostnamen an dieselbe IP-Adresse zu binden. Leider jedoch ist auch
dies in der Entwicklung von HTTP vernachlässig worden: HTTP/1.0-Anfragen übergeben den Hostnamen nicht als Teil
der Anfrage-URL. Will ein Nutzer beispielsweise die Ressource an der URL
http://example1.org/home.html
betrachten, so sendet der Browser im wesentlichen nur die Anfrage
GET /home.html HTTP/1.0
an den Server example1.org
. Da der Hostname des Servers zu einer IP-Adresse aufgelöst wird, bevor
die Anfrage gesendet wird, ist es für den HTTP-Server nicht möglich zu erkennen, an welchen Hostnamen
die Anfrage gestellt wird.
Um dieses Problem in den Griff zu bekommen, erfordert eine HTTP/1.1-Anfrage die Angabe der voll-qualifizierten
URL oder das Einschließen des Headers Host
in die Anfrage. Also sind
GET http://example1.org/home.html HTTP/1.1
und
GET /home.html HTTP/1.1
Host: example1.org
gültige Anfragen, nicht jedoch
GET /home.html HTTP/1.1
.
Wird dieser Mechanismus von allen Clients verwendet, können mehrere Hostnamen problemlos auf dieselbe IP-Adresse
abgebildet werden, da mittels des Host-Headers unterschieden werden kann.
HTTP/1.1 erweitert die 16 Statuscodes von HTTP/1.0 und macht sie erweiterbar. Auch wird ein neuer Header für Warnungen hinzugefügt. Die Statuscodes lassen sich in fünf Klassen unterteilen:
1xx: Informational | Anfrage verstanden, Verarbeitung wird fortgesetzt |
2xx: Success | Anfrage erhalten, verstanden und akzeptiert |
3xx: Redirection | Weitere Aktionen sind notwendig, um die Anfrage abzuschließen |
4xx: Client Error | Fehlerhafte oder nicht erfüllbare Anfrage |
5xx: Server Error | Server kann eine gültige Anfrage nicht erfüllen |
Durch die Fehlermeldungen der 3xx-Klasse ist es möglich, einem Client einen Hinweis zugeben, warum eine
Ressource nicht mehr verfügbar ist und wo diese sich nunmehr befindet (über den Location
Header):
GET /HTTP/300/301.html HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 301 Moved Permanently Date: Tue, 18 Jul 2000 11:45:01 GMT Content-Length: 397 Content-Type: text/html Location: http://jigsaw.w3.org/HTTP/300/Overview.html Server: Jigsaw/2.1.0 [...] GET /HTTP/300/307.html HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 307 Temporary Redirect Date: Tue, 18 Jul 2000 11:46:20 GMT Content-Length: 397 Content-Type: text/html Location: http://jigsaw.w3.org/HTTP/300/Overview.html Server: Jigsaw/2.1.0 [...]
Wie bereits dargestellt, ist die Möglichkeit, übertragene Daten zu
typisieren (über den Content-Type
Header) vielleicht entscheidend für den Erfolg von HTTP
gewesen. Die Möglichkeiten, das optimale Format einer Ressource für eine Anfrage zwischen Client und Server
auszuhandeln (Content Negotiation) sind jedoch in HTTP/1.0 noch sehr beschränkt und nur unzureichend
spezifiziert. Diesen Mangel behebt HTTP/1.1 durch eine präzise Spezifikation, wo und wie diese Aushandlung
stattzufinden hat (im Server, im Client oder sogar im Cache, dann als Transparent Content Negotiation bezeichnet
[RFC 2295]) und wie dabei im wesentlichen vorzugehen ist.
Insbesondere wird eine Syntax zur genauen Angabe der Vorlieben eines Nutzers verwendet, indem man zu jeder
akzeptablen Variante einer Ressource (z.B. einem Format, einer Sprache etc.) einen Qualitätswert zwischen
0 und 1 angeben kann. Der Ausdruck
Accept-Language: fr, de;q=0.9, en;q=0.6, x-klingon;q=0.1
bedeutet also, daß der Nutzer am liebsten Französisch spricht, aber auch mit Deutsch sehr zufrieden ist,
Englisch akzeptiert und schließlich sogar ein bißchen Klingonisch versteht.
Zur Verdeutlichung betrachte man die folgende Sitzung, die eine Ressource in verschiedenen Formaten anfordert.
GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org HTTP/1.1 300 Multiple Choices Date: Tue, 18 Jul 2000 11:39:32 GMT Content-Length: 296 Content-Type: text/html Server: Jigsaw/2.1.0 Vary: Accept <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <HTML><HEAD> <TITLE>Multiple choice for neg</TITLE> </HEAD> <BODY><ul> <li><a href="neg.txt">neg.txt</a> Q= 1.0 <li><a href="neg.html">neg.html</a> Q= 1.0 </BODY> </HTML> GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/plain HTTP/1.1 200 OK Cache-Control: max-age=172800 Date: Tue, 18 Jul 2000 11:40:48 GMT Content-Length: 9 Content-Location: http://jigsaw.w3.org/HTTP/neg.txt Content-Type: text/plain Etag: "1tgurff:q71vpin8" Expires: Thu, 20 Jul 2000 11:40:48 GMT Last-Modified: Tue, 20 Jun 2000 22:49:36 GMT Server: Jigsaw/2.1.0 Vary: Accept foo text GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: text/html HTTP/1.1 200 OK Date: Tue, 18 Jul 2000 11:41:15 GMT Content-Length: 71 Content-Location: http://jigsaw.w3.org/HTTP/neg.html Content-Type: text/html Etag: "1hnp0o5:q71vs8l8" Last-Modified: Tue, 20 Jun 2000 22:49:39 GMT Server: Jigsaw/2.1.0 Vary: Accept <HTML><HEAD><TITLE>foo text</TITLE></HEAD> <BODY>foo text</BODY></HTML> GET /HTTP/neg HTTP/1.1 Host: jigsaw.w3.org Accept: image/gif HTTP/1.1 406 Not Acceptable Date: Tue, 18 Jul 2000 11:43:17 GMT Content-Length: 266 Content-Type: text/html Server: Jigsaw/2.1.0 [...]
Es sollte klar sein, daß durch die Möglichkeit, Qualitätswerte an die Varianten zu binden und durch die drei Dimensionen des Formats (Typ, Sprache, Kodierung) der Algorithmus zur Auswahl der besten Variante keineswegs trivial ist. Content Negotiation ist weiterhin Thema der Forschung und wird auch von einer IETF-Arbeitsgruppe weiterentwickelt.
HTTP-Anfragen sind statuslos, d.h. aus der Perspektive eines Servers kann jede Anfrage (abgesehen
von Seiteneffekten) als unabhängig von jeder anderen angesehen werden. Viele Webanwendungen (z.B. E-Shops)
erfordern jedoch gerade diese Möglichkeit, z.B. um den Inhalt eines Warenkorbs über mehrere HTTP-Anfragen
verfolgen zu können.
Daher ist durch Netscape im Navigator 1.1 das Konzept der »Cookies« eingeführt und durch die IETF
(mit starken Einschränkungen) in der RFC 2109 standardisiert worden als Ergänzung
zu HTTP. Statusverwaltung ist also nicht Teil des HTTP/1.1-Standards.
Because it was used in Netscape's original implementation of state management, we will use the term cookie to refer to the state information that passes between an origin server and user agent, and that gets stored by the user agent. [RFC 2109]
Der grundlegende Mechanismus ist denkbar einfach: Ein Origin Server sendet in seiner Antwort beliebige Informationen an den Client. Der Client soll für die Speicherung der Informationen sorgen und diese mit seiner nächsten Anfrage an den Origin Server zurücksenden.
Das folgende Beispiel illustriert die typische Verwendung von Cookies:
POST /acme/login HTTP/1.1 [Daten eines Formulars]Der Benutzer identifiziert sich mittels eines Formulars.
HTTP/1.1 200 OK Set-Cookie: Customer="GAIUS_JULIUS_CAESAR"; Version="1"; Path="/acme"Der Cookie speichert die Identität des Nutzers, wobei durch
Path
angegeben wird, daß der Cookie
für alle Ressourcen auf diesem Host unterhalb von /acme
gilt.
POST /acme/pickitem HTTP/1.1 Cookie: $Version="1"; Customer="GAIUS_JULIUS_CAESAR"; $Path="/acme" [Daten eines Formulars]Der Benutzer legt eine Ware in seinen Warenkorb.
HTTP/1.1 200 OK Set-Cookie: Part_Number="BELLUM_GALLICUM"; Version="1"; Path="/acme"Warenkorb enthält nun die Ware.
POST /acme/shipping HTTP/1.1 Cookie: $Version="1"; Customer="JULIUS_CAESAR"; $Path="/acme"; Part_Number="BELLUM_GALLICUM"; $Path="/acme" [Daten eines Formulars]Der Benutzer legt die Versandart mittels eines Formulars fest.
HTTP/1.1 200 OK Set-Cookie: Shipping="IMPERIALE_FELDPOST"; Version="1"; Path="/acme"Der neue Cookie speichert die Versandart.
POST /acme/process HTTP/1.1 Cookie: $Version="1"; Customer="GAIUS_JULIUS_CAESAR"; $Path="/acme"; Part_Number="BELLUM_GALLICUM"; $Path="/acme"; Shipping="IMPERIALE_FELDPOST"; $Path="/acme" [Daten eines Formulars]Benutzer will die Bestellung abschicken.
HTTP/1.1 200 OKTransaktion ist abgeschlossen.
Neben ihrem offensichtlichen Nutzen haben Cookies in der Vergangenheit oft zu heftigen Kontroversen, insbesondere hinsichtlich Datenschutz und Sicherheit geführt. Da ihr Inhalt beliebig ist, können Cookies auch persönliche Daten wie Benutzername, Passwort etc. enthalten. Solche Informationen sind sowohl beim Transfer der Cookies, als auch auf dem lokalen Rechner gefährdet und können u.U. abgehört werden.
Neben diesen Sicherheitserwägungen können Cookies zur Überwachung des Nutzerverhaltens benützt werden
(unlängst durch die Banneragentur doubleclick.com
geschehen), wie das folgende Szenario zeigt:
http://www.example1.com/home.html
.
http://ad.example.com/adv1.gif
, einen Werbebanner.
ad.example.com
(der automatisch angenommen und gespeichert wird).
http://www.exampleB.com/home.html
.
http://ad.example.com/adv2.gif
.
ad.example.com
.
Das Problem ist offensichtlich: Der Benutzer erhält einen (Third-Party-) Cookie von einer Seite, die er
nicht einmal besucht hat (unverifiable transaction).
Diese Möglichkeit kann ausgenutzt werden, um das Nutzungsverhalten festzustellen, wenn nur genügend Seiten
beispielsweise auf einen Werbungsserver verweisen.
Cookies, die aus unverifiable transactions stammen, sollen nach [RFC 2109] durch den User Agent zurückgewiesen werden. Diese Forderung ist jedoch auf massiven Widerstand gestossen und von den meisten existierenden User Agents nicht umgesetzt.
Da es auch technische Bedenken hinsichtlich des Cookie-Systems gibt (Overhead), wird der Standard gerade einer umfassenden Revision unterzogen.
Bekanntlich erlaubt HTTP/1.0 eine rudimentäre Authentifizierung, wobei jedoch Benutzername und Passwort unverschlüsselt übertragen werden. Daher ist für HTTP/1.1 eine bessere Methode entwickelt und standardisiert worden ([RFC 2617]): Digest Authentication. Die Idee ist, daß ein Server nicht einfach Benutzername und Passwort anfordert, sondern diese Anforderung durch einen nur einmal gültigen Wert anreichert (nonce). Der Client bildet nun eine Quersumme (üblicherweise nach dem MD5-Verfahren) über Benutzername, Passwort, nonce, der HTTP-Methode der Anfrage und der angeforderten URI. Die Vorteile sind offensichtlich: Das Passwort wird nicht unverschlüsselt übertragen und die Antwort ist stets nur für eine Anfrage gültig, so daß mit ihr keine anderen Anfragen authentifiziert werden können.
Auch dieses Authentifizierungsschema ist noch recht eingeschränkt, da es sich weiterhin auf ein shared secret stützt, dessen sicherer Austausch in einem globalen Netz keineswegs trivial ist. Als Ersatz für die einfache Authentifizierung in HTTP/1.0 stellt es jedoch einen großen Schritt dar.
Es sollte mittlerweile deutlich geworden sein, daß sich HTTP in der Version 1.1 weit von seinen einfachen Ursprüngen entfernt hat. Die Präambel der RFC ist gegenüber der Version 1.0 fast gleich geblieben, mit einer bezeichnenden Ausnahme: Die Worte lightness und speed wurden gestrichen. So gilt HTTP/1.1 heute eher als unhandlich und ineffizient:
HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. [Stal 2000]
Zwar hat HTTP/1.1 einen großen Teil der offensichtlichen Probleme der ersten (informellen) Spezifikation gelöst, ist aber in vielen Bereichen inkonsequent (Erweiterbarkeit, Content Negotiation) und kann einige der selbstgesteckten Ziele nicht erreichen.
HTTP/1.1 differs from HTTP/1.0 in numerous ways, both large and small. While many of these changes are clearly for the better, the protocol description has tripled in length, and many of the new features were introduced without any real experimental evaluation to back them up. The HTTP/1.1 specification also includes numerous irregularities for compatibility with the installed base of HTTP/1.0 implementations. This increase in complexity complicates the job of client, server, and especially proxy cache implementors. It has already led to unexpected interactions between features, and will probably lead to others. We do not expect the adoption of HTTP/1.1 to go entirely without glitches. Fortunately, the numerous provisions in HTTP/1.1 for extensibility should simplify the introduction of future modifications. [Kris 1998]
Das größte Problem stellt tatsächlich aktuell die fehlende oder fehlerhafte Unterstützung der Erweiterungen in HTTP/1.1 durch die üblichen HTTP-Server und User Agents dar. Erst unlängst (August 1999) hat eine Studie über die Protokoll-Konformität üblicher Webserver erschreckende Resultate gebracht:
Our Experiments show that even though many of the popular sites claim to run HTTP/1.1, some fail the basic compliancy requirement, while others run with many of the significant improvements turned off. [Kris 1999]
In Abschnitt 3.3.3 haben wir bereits
Beispiele für eine inkorrekte Umsetzung des Standards gesehen. Gerade die neuen Methoden, wie
OPTIONS
werden häufig nicht konform umgesetzt, andererseits werden permanent neue
Features hinzugefügt, ohne die möglichen Folgen zu überblicken, wie die
folgende Sitzung zeigt:
OPTIONS * HTTP/1.1 Host: www.microsoft.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sun, 23 Jul 2000 02:01:57 GMT Content-Length: 0 Accept-Ranges: bytes DASL: <DAV:sql> DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Cache-Control: private
Genauso ungenügend ist die Unterstützung auf Seiten der User Agents, man betrachte dazu die folgenden Header üblicher Web-Browser:
Navigator 4.6 Windows 98 |
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Language: de,en Connection: Keep-Alive Host: privacy.net User-Agent: Mozilla/4.6[de]C-CCK-MCD QXW0321j (Win98; I) Accept-Encoding: gzip Accept-Charset: iso-8859-1,*,utf-8 |
Internet Explorer 5.5 Windows 98 |
Accept: application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: de Connection: Keep-Alive Host: privacy.net Referer: http://privacy.net/ User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Accept-Encoding: gzip, deflate |
Opera 4.0B3 Windows 98 |
Accept: image/gif, image/x-xbitmap, image/jpeg, text/html, */* Connection: Keep-Alive Host: privacy.net User-Agent: Mozilla/4.72 (Windows 98;US) Opera 4.0 Beta 3 [en] Accept-Encoding: identity, *;q=0 |
Amaya Linux |
Accept: */* Connection: TE,Keep-Alive Host: privacy.net User-Agent: amaya/V2.4 libwww/5.2.9 Accept-Encoding: *,deflate TE: trailers,deflate |
Lynx Linux |
Accept: text/html, text/plain, image/jpeg, image/*, application/x-gunzip, application/x-gzip, application/x-bunzip2, application/x-tar-gz, video/*, text/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm,image/gif, application/postscript, */*;q=0.01 Accept-Language: en Host: privacy.net User-Agent: Lynx/2.8.3dev.9 libwww-FM/2.14 Accept-Encoding: gzip, compress |
XEmacs 21.1 Linux |
Accept: multipart/alternative, multipart/mixed, multipart/*,application/x-x509-ca-cert, application/x-x509-user-cert,application/octet-stream, application/dvi,application/emacs-lisp, application/x-tar,application/x-latex, application/x-tex, application/latex,application/tex, application/texinfo, application/zip,application/pdf, application/postscript, audio/x-mpeg,audio/*, message/rfc-*822, image/x-xwd, image/x11-dump,image/windowdump, image/*, text/plain, text/enriched, text/html, video/mpeg, x-world/x-vrml, archive/tar Host: privacy.net:80 Referer: http://privacy.net User-Agent: Emacs-W3/4.0pre.46 URL/p4.0pre.46 (i386-suse-linux; X11) MIME-Version: 1.0 Extension: Security/Digest Security/SSL Accept-encoding: base64, 7bit, 8bit, binary, x-compress, x-gzip, compress, gzip, x-hqx, quoted-printabl |
Man sieht, daß die Behandlung der für Content Negotiation verwendeten Header inkonsistent und nicht
konform ist: Insbesondere die Verwendung von */*
zusammen mit anderen Varianten ohne
Qualitätswert ist nach Standard nicht sinnvoll, da die Bedeutung dann stets ist: Alle Varianten sind
gleich geeignet. Eine Bevorzugung nach Reihenfolge findet nicht statt (auch wenn dies bei HTTP/1.0
üblich war und daher immer noch verwendet wird, aber selbst bei dieser Semantik ist der
Accept-Encoding
Header von Netscape sinnlos). Der Accept-Encoding
Header von Opera ist
in der durch den Standard empfohlenen Syntax.
Im Rahmen der Entwicklung der nexten Generation von Transfer-Protokollen entfaltet insbesondere
das W3C eine Anzahl Aktivitäten zur Bestimmung der Anforderungen an ein solches Protokoll im
Rahmen der Web Characterization Activity
(http://www.w3.org/WCA/
). Es wird versucht,
Charakteristika des WWW festzustellen, wie (Daten aus dem Jahr 1999)
Diese Erkenntnisse können in vielerlei Hinsicht zum besseren Verständnis der Anforderungen an ein
Transfer-Protokoll führen, wenn sie richtig bewertet werden (so heißt die Inakzeptanz von SSL nicht, daß
keine Sicherungstechnologie auf Transportebene erforderlich wäre, sondern daß SSL diese Aufgabe, vor allem
wegen der Nutzung eines eigenen URI-Schemas (https
), unzureichend erfüllt). Beispielsweise
zeigt die erste Feststellung, daß Second-Level-Caches für mehrere Nutzer (Proxy-Caches) ein hohes Potential
an Bandbreiten-Einsparung besitzen und weiterhin zentraler Punkt eines Transfer-Protokolls bleiben müssen.
Weiterhin läßt sich beobachten, daß viele Ressourcen sich zwar häufig, aber stets nur minimal ändern. Für
solche Ressourcen läßt sich drastisch Bandbreite einsparen, wenn ein Cache, anstatt die gesamte Ressource
erneut anzufordern, nur die Änderungen abrufen und auf die gespeicherte Ressource anwenden könnte
(Delta-Transfer, vgl. [Kris 1997]).
Die wichtigste Schlußfolgerung aus den Erfahrungen mit HTTP/1.1 ist, daß künftige Protokollversionen so gestaltet sein müssen, daß sowohl die Hersteller von Servern, als auch von Browsern die neuen Möglichkeiten einsetzen wollen, da sonst wiederum die Umstellung zu großen Problemen führen dürfte.
Schließlich ist HTTP ein durch Menschen lesbares Protokoll in ASCII-Codierung, wodurch der Overhead zur Übertragung und zum Parsen der Nachricht deutlich anwächst:
Automatable, machine-readable messages are different from human readable messages even though they may both be encoded using ASCII strings. The choice of MIME based header encoding in HTTP has led to the general misconception that HTTP is intended as a human readable protocol. The result has been verbose messages and extremely complicated parsers. As an example, a typical HTTP request is about 250 bytes long. Due to the nature of typical Web usage, subsequent requests are often closely related leading to about 90% in redundancy between requests. This means slowing down information exchange over low bandwidth connections. [Niel 1998a]
Neben diese offensichtlichen Anforderungen an eine Weiterentwicklung treten noch einige, nicht weniger wichtige, aber sehr kontroverse Anforderungen resultierend aus der künftigen Entwicklung des WWW, von denen einige hier genannt werden sollen:
The most obvious battle over adaptive reuse, and the one that likely has the most dollars at stake, is the current battle over HTTP. The arrival of XML-RPC—and particularly SOAP—has meant that developers are treating what was once a publishing protocol, with limited two-way communications, as a full-blown peer-to-peer communications protocol. While these protocols continue to use HTTP to transport documents, the contents of those documents have been given new status in the processing of requests and responses. [...]
In some ways, it's deeply ironic that SOAP and XML-RPC are reusing the HTTP protocol rather than starting fresh and building a simpler transport for XML information. The HTTP infrastructure is well-understood, incredibly widely deployed, and offers the promise of crossing firewall boundaries. Yet HTTP is also rather inefficient, subject to caching along the way, and not always the best choice for transmitting short disconnected messages.
A generic XML transmission protocol, something like the Extensible Protocol, or perhaps optimized for shorter messages, seems like something that could be very useful for a wide range of XML-based communication. A generic foundation might open the way for large-scale exchange of XML messages of many different varieties, using a shared and easily internationalized infrastructure.
(Simon St. Laurent,
http://www.xml.com/pub/2000/06/21/disruption/index.html
)
All diese Entwicklungen sollen zu einer neuen Generation von HTTP führen: HTTP-ng [Niel 1998a]. Die grundlegenden Ziele sind:
HTTP-ng soll zum Erreichen dieser Ziele eine Schichtarchitektur mit einer verteilten Plattform als Grundlage verwenden. Bisher ist jedoch nicht klar, ob und wie weit diese Ideen sinnvoll sind oder jemals umgesetzt werden. Insbesondere nehmen die bisherigen Ansätze keine Rücksicht auf die inhaltliche Entwicklung des WWWs und eine mögliche Veränderung des Nutzungsverhaltens.
Wie wird sich HTTP entwickeln?
Thus, some HTTP servers evolved so that the components no longer produced a rendering output such as WML or HTML, but a more abstract model. The components became service components. They responded to requests by producing documents structured with XML-based service document types, instead of documents structured with XML-based rendering document types. When the consumer was a ›user agent‹ (a device that interpreted the received document into something accessible to the senses), the HTTP server sent a document structured with a rendering language document type. When the consumer was another server, the document was structured with a service language document type. Both kinds of languages were still based on the XML meta-language (i.e., the common alphabet). After all, XML wasn't a language, it was more a set of rules used to create languages.
(Didier Martin, A Campfire Story,
http://www.xml.com/pub/2000/07/19/campfire/index.html
)
http://www.ietf.org/rfc/rfc1945.txt
Informational RFC zu HTTP/1.0. Die meisten aktuellen Webserver implementieren mittlerweile weitgehend HTTP/1.1.
http://www.ietf.org/rfc/rfc2616.txt
Die kanonische Beschreibung, Definition des Formats der Messages, Header etc. von HTTP. RFC 2068 ist damit überholt und sollte nicht mehr verwendet werden.
http://www.ietf.org/rfc/rfc2617.txt
Beschreibung der Authentifikationsmethoden für HTTP/1.1.
http://www.ietf.org/rfc/rfc2295.txt
Beschreibung der transparenten Inhaltsaushandlung in HTTP/1.1, Vorstellung verschiedener Algorithmen.
http://williamstallings.com/DCC6e.html
Standardwerk zur Kommunikation mit Hilfe des Computers. Technische, aber umfassende Beschreibung der Internet-Architektur und aller wichtigen Application-Layer-Protokolle (HTTP, SMTP, FTP etc.).
http://www.manning.com/Hethmon/index.html
Wie schreibe ich meinen eigenen HTTP-Server? Leider vergriffen, aber die ersten beiden Kapitel sind online verfügbar.
http://www.w3.org/Protocols/HTTP/
Einige historische Dokumente und Working Drafts, Übersicht über die W3C-Aktivitäten rund um HTTP.
http://jigsaw.w3.org/HTTP/
Hier kann man einen großen Teil der Erweiterungen von HTTP/1.1 testen.
http://www.ietf.org/html.charters/http-charter.html
Überblick über die Aktivitäten des IETF im Umfeld von HTTP, HTTP-Working Group, Übersicht über alle relevanten RFCs und Internet Drafts.
http://privacy.net/analyze
Komplette Analyse aller Informationen, die über den Nutzer einer Webseite ermittelt werden können. Unter anderem wird auch der vom User Agent gesendete HTTP-Header ausgegeben.
http://www.lrz-muenchen.de/services/netzdienste/www/www-security/
Schnelle Analyse, Informationen, wie man sich vor dem Ausspionieren von persönlichen Informationen durch Server schützen kann.
http://www.delorie.com/web/headers.html
HTTP Header-Viewer für Antworten beliebiger Server.
http://www.junkbuster.com/cgi-bin/show_http_headers
HTTP-Header-Viewer für Anfragen des User Agents.
http://www.w3.org/Protocols/HTTP-NG/1998/11/draft-frystyk-httpng-overview-00
http://www.alternic.org/drafts/drafts-f-g/draft-frystyk-httpng-overview-00.txt
Darstellung der Problematik, der Anforderungen und eines grundlegenden Lösungsansatzes.
http://www.w3.org/TR/1998/WD-HTTP-NG-goals.html
Darstellung der Ziele des HTTP-NG Projekts.
http://www.w3.org/TR/WD-HTTP-NG-architecture/
Vorschlag für eine zukünftige Architektur von HTTP, Implementations- und Evaluationsphase.
http://www.ietf.org/rfc/rfc2774.txt
Universeller Erweiterungsmechanismus für HTTP.
http://www.w3.org/Protocols/HTTP/AsImplemented.html
Beschreibung der ursprünglichen Implementation von HTTP nach Berners-Lee.
http://www.ietf.org/rfc/rfc2396.txt
Beschreibung der allgemeinen Syntax von URIs durch eine formale Grammatik (etwa EBNF).
http://www.ietf.org/rfc/rfc2109.txt
Beschreibung der Verwendung und Implementierung von Cookies als Mechanismus zum Zustandsmanagement in HTTP. Offizieller Standard, aber nicht Teil der HTTP-Spezifikation.
http://www.w3.org/Protocols/MUX/WD-mux-980708.html
Working Draft zu einem Multiplex-Transferprotokoll, daß es erlauben soll, n Anfragen gleichzeitig an einen Server stellen zu können, ohne dafür n Verbindungen öffnen zu müssen.
http://www.isi.edu/lsam/publications/http-perf/index.html
Geschwindigkeit von HTTP, insbesondere über verschiedene Zugangstechnologien.
http://www.isi.edu/~johnh/PAPERS/Heidemann96a.html
Umfassende Analyse der Performance von HTTP über verschiedene Transport Protokolle, Modell zur Messung der HTTP-Performance, Probleme von HTTP over TCP.
http://mosquitonet.stanford.edu/~laik/projects/wireless_http/publications/tech_report/html/index.html
http://gunpowder.stanford.edu/~laik/projects/wireless_http/publications/tech_report/html/index.html
Schwerpunkt auf den Besonderheiten von kabellosen Netzwerken, Mobilfunk.
http://www.research.att.com/~bala/papers/h0vh1.html
http://www8.org/w8-papers/5c-protocols/key/key.html
Umfassende und klare Zusammenfassung der wesentlichen Unterschiede zwischen HTTP/1.0 und HTTP/1.1.
http://www.w3.org/Protocols/HTTP/Performance/Pipeline
Darstellung des erhofften Effekts durch HTTP/1.1, CSS1 (weniger Formatierungsanweisungen) und PNG (bessere Kompressionsrate) auf die zu übertragende Datenmenge.
http://ei.cs.vt.edu/~succeed/WWW4/WWW4.html
Wie hoch ist die maximale Hit-Rate für einen Proxy- (Second-Level-) Cache? Wie hoch ist die durchschnittliche Rate? Wovon hängt die Hit-Rate ab?
http://www.research.att.com/~bala/papers/procow-1.ps.gz
Umfassende Studie über die korrekte Umsetzung des HTTP/1.1-Standards in verschiedenen populären Websites.
http://www.research.att.com/~bala/papers/sigcomm97.ps.gz
Verwendung von Delta Encoding in HTTP.