15. Das Hypertext Transfer Protokoll 15-1 HTTP - Überblick 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies)
15. Das Hypertext Transfer Protokoll 15-2 HTTP Kommunikation (1)Request Beispiel: Die folgende URL werde angefordert (Request) http://www.informatik.uni-halle.de/index.html Schritte des Basis-Modells der HTTP-Kommunikation: 1. Öffnen der TCP-Verbindung zum Web-Server. 2. Senden eines Requests zum Web-Server. 3. Empfangen eines Responses vom Web-Server (enthält die Daten der requesteten Web-Seite). 4. Schließen der Verbindung (optional).
15. Das Hypertext Transfer Protokoll 15-3 HTTP Kommunikation (2) Erster Schritt: Öffnen der TCP-Verbindung Die URL (Web-Adresse) enthält den Namen des Web-Servers: www.informatik.uni-halle.de. Der Browser fragt einen DNS-Server nach der IP- Adresse. Wird die IP-Adresse nicht gefunden, gibt Opera z.b. aus: Ein Zugriff auf den Server ist nicht möglich.
15. Das Hypertext Transfer Protokoll 15-4 HTTP Kommunikation (3) Der Client (Browser) öffnet eine TCP-Verbindung zum Port 80 dieser Maschine (141.48.2.8). 80 ist die Standard Port Nummer für HTTP. Man kann eine andere Portnummer in der URL festlegen. Wenn kein Prozess auf diesen Port hört, Opera gibt die Fehlermeldung Die Verbindung zum Server konnte nicht hergestellt werden. Will man den Request manuell eingeben, kann man die TCP-Verbindung auch öffnen mit telnet www.informatik.uni-halle.de 80
15. Das Hypertext Transfer Protokoll 15-5 HTTP Communication (4) Zweiter Schritt: Request Der Client (Browser) fordert ein Objekt (File) vom Server. Das geschieht mit der Nachricht GET /index.html HTTP/2.0 (Leerzeile) Zwischen der GET-Zeile und der Leerzeile können viele Optionen ( Headers ) spezifiziert werden. Die Leerzeile wird zur Markierung des Endes des GET-Requests gebraucht. Der Client schließt die Verbindung nicht sofort nach dem Request, damit der Server eine Möglichkeit hat, festzustellen, ob der Request vollständig ist. POST-Requests enthalten Daten nach der Leerzeile. Der Header gibt an, wie viele Bytes der Server noch nach der Leerzeile lesen muss.
15. Das Hypertext Transfer Protokoll 15-6 HTTP Communication (5) Beispiel für einen einfachen Request - Handeingabe: Öffnen der Verbindung mit TELNET: telnet set localecho o dbs.informatik.uni-halle.de 80 GET /Lehre/asq17 18/test.html HTTP/2.1 Host:dbs.informatik.uni-halle.de (Leerzeile) set localecho hat eigentlich mit dem Request nichts zu tun. Es sichert nur die Ausgabe der Eingabeanforderungen. Wenn Seiten mehrsprachig angeboten werden, so können noch entsprechende Endungen ( z. B..de.en) angehängt werden.
15. Das Hypertext Transfer Protokoll 15-7 HTTP Kommunikation (6) Dritter Schritt: Response Der Server antwortet mit dem angeforderten (requesteten) Dokument, z. B. er überträgt eine HTML- Datei. Vor den Daten wird ein Status-Code gesendet (z.b. 200 OK ), sowie Informationen über das Dokument (Meta-Daten) und über den Server. Header und Daten sind durch eine Leerzeile getrennt.
15. Das Hypertext Transfer Protokoll 15-8 HTTP Kommunikation (7) Vierter Schritt: Verbindung schließen Früher wurde der Server nach dem Transfer der angeforderten Daten geschlossen. Das wurde jedoch ineffizient, weil öfter weitere Dateien (Bilder, mehr Webseiten ) vom selben Server übertragen werden mussten. Deshalb müssen Client und Server übereinstimmen, um die TCP-Verbindung für eine bestimmte Zeit zu sichern. Das geht über den Header Connection:.
15. Das Hypertext Transfer Protokoll 15-9 HTTP Kommunikation (8) Wenn der Client weiss, dass er verschiedene Dokumente vom Server braucht, kann er einen Request nach dem anderen senden ohne auf den Response zu warten. Das wird pipelining genannt. Frühere Browser wurden für viele gleichzeitige Verbindungen zum selben Server geöffnet. Das belastete stark. Heute werden in der Regel vom Client nicht mehr als zwei gleichzeitige Verbindungen auf demselben Server geöffnet.
15. Das Hypertext Transfer Protokoll 15-10 Proxies (1) Manchmal kommunizieren Clients (Browser) und Server über einen oder mehrere Proxy Server (Caches): Browser Request Response Proxy Request Response Server Browser können so konfiguriert werden, dass sie alle Requests an einen festen Proxy-Server anstelle an den echten Server senden.
15. Das Hypertext Transfer Protokoll 15-11 Proxies (2) Der Proxy prüft dann, ob die gewünschte Web- Seite in seinem Cache vorhanden ist. Er versucht auch zu überprüfen, ob die Seite immer noch aktuell ist, siehe unten. Wenn ja, antwortet der Proxy mit dem Request aus seinem Cache.
15. Das Hypertext Transfer Protokoll 15-12 Proxies (3) Wenn nicht sendet der Proxy den Request an den realen Server ( Origin Server ) oder an einen anderen Proxy. Er leitet den Response (Antwort) an den Client und zusätzlich in seinen Cache (für künftige Requests auf die gleiche URL).
15. Das Hypertext Transfer Protokoll 15-13 HTTP Kommunikation sichtbar machen Um Informationen über die Arbeit des Netzwerkes zu erhalten, kann man sich bei Verwendung des Browsers Firefox mit der Tastenkombination Strg+Umschalttaste+I oder Strg+Umschalttaste+Q die Laufzeitanalyse bzw. die Netzwerkanalyse sichtbar machen.
15. Das Hypertext Transfer Protokoll 15-14 Syntax eines Requests (1) Ein Request besteht aus einer Kommandozeile, null oder mehreren Headern, einer Leerzeile, einem Body (Entity, Daten) (optional). Eine Request Kommandozeile besteht aus einer Methode, z.b. GET. einer Identifizierung der Resource, auf welche die Methode angewandt werden soll (z.b. absoluter Pfad) der HTTP-Version des Requests. z.b. HTTP/1.1.
15. Das Hypertext Transfer Protokoll 15-15 Syntax eines Requests (2) Es gibt vier Klassen von Header: General Header: In Request und Response, egal, ob sie die Daten enthalten oder nicht. Entity Header: In Request und Response, aber nur wenn Daten enthalten sind (Entity). Request Header: Nur in einem Request. Response Header: Nur in einem Response. Die Syntax der Header ist die gleiche wie in Emails (z.b. From: ), siehe RFC 822. Die spezifische Auswahl möglicher Header ist natürlich unterschiedlich.
15. Das Hypertext Transfer Protokoll 15-16 Methoden (1) GET: Die Daten, gespeichert unter dem gegebenen Pfad/URI werden angefordert (Request) Dies kann der Inhalt einer Datei auf dem Server sein, aber der Pfad/URI kann auch ein Programm identifizieren, welches Daten berechnet. Das hängt von der Server-Konfiguration ab und sogar eine einfache URL, die aussueht wie ein Dateiname kann berechnet worden sein. Argumente/Parameter kann im Anhang nach einem? folgen. HEAD: Wie GET, kann aber nur den Header liefern, nicht die Daten (Body). Z.B. erhält man auf diese Weise das Datum der letzten Änderung, die Größe der Datei, den MIME-Typ, tec. (Meta-Daten).
15. Das Hypertext Transfer Protokoll 15-17 Methoden (2) POST: Die Daten werden vom Client zum Server übertragen zur gegebenen URI übertragen. Das ist die häufigste Anwendung für Daten aus Formularen. Auch die GET Methode kann zum Übertragen von Formulardaten zum Server verwendet werden. Aber die Formulardaten werden dann auf dem Server gespeichert und nicht nur zum Berechnen einer Ergebnis-Webseite benutzt (z.b. query forms). POST ist vorzuziehen. Die URI kann jedoch auch den Namen einer newsgroup enthalten.
15. Das Hypertext Transfer Protokoll 15-18 Methoden (3) POST, weiterhin: Die URI kann auch Datenbank-Tabellen benennen, in die Daten als neuer Datensatz eingefügt sind. Oder die URI benennt ein Dokument an welches Daten angehängt werden. Was genau passiert ist abhängig von der Konfiguration des Servers (und der URI). HTTP schreibt keine spezifische Aktion vor.
15. Das Hypertext Transfer Protokoll 15-19 Syntax eines Response (1) Ein Response besteht aus: Status-Zeile, null oder mehreren Header, Leerzeile, Body (Entity, Daten, Dokument) (optional). Eine Status-Zeile besteht aus: HTTP-Version, Status-Code (drei Zahlen) (z.b. Fehlernummer), Text, der den Status-Code erklärt. Status-Code: für den Computer, Text: für den Nutzer.
15. Das Hypertext Transfer Protokoll 15-20 Status-Codes: Beispiele Status-Codes bestehen aus drei Zahlen. Die erste Zahl legt die Hauptklasse des Status-Codes fest. Unter Wikipedia sind alle Statuscodes aufgelistet. 2xx: Successfull: 200: OK Die angeforderte Operation wurde erfolgreich ausgeführt. Z.B. eine angeforderte Web-Seite wurde erfolgreich beantwortet (response). 206: Partial Content. Der Client hat explizit nur einen teil der Resource angefordert und dieser ist erfolgreich beantwortet worden.
15. Das Hypertext Transfer Protokoll 15-21 Overview 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies)
15. Das Hypertext Transfer Protokoll 15-22 Medientypen (1) Mit Hilfe von Content-Negotiation (Inhaltsvereinbarung) wird zwischen verschiedenen Medientypen einer Ressource gewählt, die sich in Bezug auf Sprache, Qualität, Codierung oder andere Parameter unterscheiden können, aber keinen Einfluß auf den Inhalt einer Ressource haben.
15. Das Hypertext Transfer Protokoll 15-23 Medientypen (2) Die Medientypen werden in der Art der MIME Standards ( Multipurpose Internet Mail Extensions ) festgelegt. Die Medientypen haben eine Hauptklasse und einen Subtyp, z.b. image/gif. Wenn der Client den Subtyp nicht kennt, kann er aus der Hauptklasse Informationen entnehmen, was zu tun ist.
15. Das Hypertext Transfer Protokoll 15-24 Medientypen (3) Z.B., alle text/* Typen sollen so dargestellt werden, dass der Client in der Lage ist, sie lesbar zu zeigen. E.g. text/postscript ist falsch, es muss application/postscript geschrieben werden. Außer Hauptklasse und Subtyp können auch optionale Parameter spezifiziert werden, (getrennt mit ; ), z.b. text/html; charset=iso-8859-4.
15. Das Hypertext Transfer Protokoll 15-25 Medientypen (4) Die zur Zeit definierten Klassen sind: text, z.b. text/plain, text/html, text/xml. multipart, z.b. multipart/mixed. message, z.b. message/rfc822, message/news. application, z.b. application/octet-stream, application/postscript, application/pdf. image, z.b. image/jpeg, image/gif, image/png. audio, z.b. audio/basic, audio/mpeg. video, z.b. video/mpeg, video/quicktime.
15. Das Hypertext Transfer Protokoll 15-26 Medientypen (5) Die Medientypen sind registriert bei IANA (Internet Assigned Numbers Authority) [http://www.iana.org]. Die derzeitige Liste der Medientypen kann nachgesehen werden bei [http://www.iana.org/assignments/media-types] Nicht-registrierte Formen beginnen mit x-.
15. Das Hypertext Transfer Protokoll 15-27 Alternative Versionen (1) Ein Dokument mit der gleichen Bezeichnung kann auf dem Server in unterschiedlichen Formaten existierent Z.B. ASCII, HTML, LAT E X, Postscript, PDF. Es ist auch möglich, dass das Dokument in verschiedenen Sprachen existiert (z.b. Deutsch und Englisch). z.b. Es ist möglich, dass die Homepage der Universität Halle die URI http://www.uni-halle.de/ auf deutsch oder auf englisch geliefert wird, je nach Vorgaben des Clients.
15. Das Hypertext Transfer Protokoll 15-28 Alternative Versionen (2) Der Apache hat auch Type Maps. Die URI zeigt auf ein File, das unterschiedliche Versionen beschreibt. Z.B. unter doc.var kann folgendes gespeichert sein: URI: doc.html.en Content-Type: text/html; qs=1 Content-Language: en Description: "English Original" URI: doc.html.de Content-Type: text/html; qs=0.8 Content-Language: de Description: "Deutsche Übersetzung"
15. Das Hypertext Transfer Protokoll 15-29 Selektion des Zeichensatzes Der Client kann spezifizieren, welchen Zeichensatz (encodings)er verwenden will: Accept-Charset: ISO-8859-1, ISO-8859-5;q=0.8 Z.B. gibt es für kyrillische Buchstaben mehrere Zeichensätze (ISO-8859-5, windows-1251). Der Server kann übersetzen zwischen unterschiedlichen Codierungen.
15. Das Hypertext Transfer Protokoll 15-30 Kompressions-Methoden Der Client kann wählen, welche Kompressionsmethode er versteht: Accept-Encoding: gzip;q=1, identity;q=0.5 Formate aus der HTTP-Spezifikation: gzip (früher x-gzip): GNU gzip. compress (früher x-compress): UNIX compress. deflate. identity: Keine Kompression.
15. Das Hypertext Transfer Protokoll 15-31 Overview 1. Requests and Responses 2. Content Negotiation 3. State Management (Cookies)
15. Das Hypertext Transfer Protokoll 15-32 Protokoll ohne Status HTTP ist ein statusloses Protokoll: Jeder Request wird isoliert behandelt. Es gibt keine sessions mit login und logout. Das verringert die Server-Last: Nachdem es einen Request beantwortet hat, kann das Ergebnis vollständig vergessen werden. Demgegenüber würden Sessions irgendeinen Speicher auf dem Server während der gesamten Dauer der Session (die lang sein kann), benötigen, um Status-Informationen zu speichern. Aber das bedeutet, dass wir zurück zu den Zeiten des Batch-Prozessing gehen müssten: Der Request muss alle notwendigen Daten enthalten.
15. Das Hypertext Transfer Protokoll 15-33 Cookies (1) Jedoch in vielen on-line-shops, kann man Waren mit einer shopping cart erwerben und am Ende bezahlen. offensichtlich werden Waren von einer ganzen Reihe von Requests zusammen auf einem Server behandelt wie eine Session. das wird normalerweise mit Cookies realisiert. Der Server sendet zum Client und der Client schließt im allgemeinen alle künftigen Requests des gleichen Servers mit ein.
15. Das Hypertext Transfer Protokoll 15-34 Cookies (2) Ein Cookie kann z.b. Session-Nummer enthalten. Z.B. telnet www.altavista.com 80: eine User-Nummer oder eine HTTP/1.0 200 OK Date: Thu, 14 Dec 2000 16:12:20 GMT Server: AV/1.0.1 MIME-Version: 1.0 Content-Length: 18713 Content-Type: text/html; CHARSET=ISO-8859-1 Set-Cookie: AV_USERKEY=AVSe36e6eef1b00004b0910ac0008d5f; expires=tuesday, 31-Dec-2013 12:00:00 GMT; path=/; domain=.altavista.com;
15. Das Hypertext Transfer Protokoll 15-35 Cookies (3) Das bedeutet, dass das Cookie zu allen Web-Servern in der Domain.altavista.com geschickt werden sollte, wenn Zugriff zu den Seiten besteht (path=/). Die Browser senden die Daten mit dem Header. Cookie: AV_USERKEY=AVSe36e6eef1b00004b0910ac0008d5f; Auf diese Art und Weise wird das Führen von Status- Informationen vom Server auf den Client übertragen. Aber häufig ist der Inhalt eines Cookies nur eine Referenz auf Status- Informationen, die tatsächlich auf dem Server gesichert sind.
15. Das Hypertext Transfer Protokoll 15-36 Cookies (4) Browser so können konfiguriert werden, dass sie Cookies ignorieren. Manche Online-Shops arbeiten nicht ohne Cookies. Man kann Cookies von Zeit zu Zeit löschen.
15. Das Hypertext Transfer Protokoll 15-37 Private Probleme Cookies machen es möglich, Nutzer zu identifizieren. Beispiel: Ein Online-Buchshop sendet eine Nutzer-Nummer in einem Cookie, wenn ein Nutzer zum ersten Mal auf seine Webseite zugreift. Der Browser sendet diese Nutzer-ID zurück, wenn künftig auf die Seite zugegriffen wird. Wenn der Nutzer ein Buch kauft, erfährt er Namen und Adresse von dieser Nutzer-ID. Wenn der Nutzer später nur Angebote im Buch- Shop anschaut, ist sein/ihr Name bekannt.