15. Das Hypertext Transfer Protokoll 15-1 15. Das Hypertext Transfer Protokoll 15-2 HTTP - Überblick HTTP Kommunikation (1)Request 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies) 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 15. Das Hypertext Transfer Protokoll 15-4 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. HTTP Kommunikation (3) Der Client (Browser) öffnet eine TCP-Verbindung zum Port 80 dieser Maschine (141.48.3.159). 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 15. Das Hypertext Transfer Protokoll 15-6 HTTP Communication (4) Zweiter Schritt: Request Der Client (Browser) fordert ein Objekt (File) vom Server. Das geschieht mit der Nachricht GET /index.html HTTP/1.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. 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/asq10 11/stud.sql HTTP/1.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 15. Das Hypertext Transfer Protokoll 15-8 HTTP Kommunikation (6) HTTP Kommunikation (7) Beispiel für einen Request, der von Netscape 4.76 gesendet wurde: GET /index.html HTTP/1.0 Referer: http://www.informatik.uni-halle.de/.../c3.html Connection: Keep-Alive User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u) Host: haendel.informatik.uni-halle.de:8080 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 (Leerzeile) Beispiel für einen Request, vom Internet Explorer: GET /index.html HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Referer: http://www.informatik.uni-halle.de/.../c3.html Accept-Language: en-us,de;q=0.5 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) Host: haendel.informatik.uni-halle.de:8080 Connection: Keep-Alive (Leerzeile)
15. Das Hypertext Transfer Protokoll 15-9 15. Das Hypertext Transfer Protokoll 15-10 HTTP Kommunikation (8) Ein Request kann Daten enthalten (z.b. aus einem Formular): POST /db-cgi/grades?view HTTP/1.0 Referer: http://.../lehre/asq10 11/view.html Connection: Keep-Alive User-Agent: Mozilla/4.73 [en] (X11; U; SunOS 5.7 sun4m) Host: www.informatik.uni-halle.de Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Content-type: application/x-www-form-urlencoded Content-length: 46 first_name=annemarie&last_name=herrmann&password=abc HTTP Kommunikation (9) 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-11 15. Das Hypertext Transfer Protokoll 15-12 HTTP Kommunikation (10) HTTP Kommunikation (11) Beispiel für ein Response vom Apache Server: HTTP/1.1 200 OK Date: Thu, 02 Jul 2009 18:52:10 GMT Server: Apache/1.3.12 (Unix) Last-Modified: Mon, 08 May 2008 09:22:58 GMT ETag: "60304-46b-39168772" Accept-Ranges: bytes Content-Length: 1131 Connection: close Content-Type: text/html... HTML Dokument... Beispiel für ein Response vom Microsoft Internet Information Server (IIS): HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Content-Location: http://141.48.3.159/default.htm Date: Thu, 02 Jul 2009 19:00:39 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Thu, 06 Mar 2008 23:41:04 GMT ETag: "fca66ec6a084bf1:abe" Content-Length: 4263... HTML Dokument...
15. Das Hypertext Transfer Protokoll 15-13 15. Das Hypertext Transfer Protokoll 15-14 HTTP Kommunikation (12) HTTP Kommunikation (13) Auf diesem Weg können beliebige Dateien übertragen werden, nicht nur HTML: HTTP/1.1 200 OK Date: Fri, 03 Jul 2009 07:35:20 GMT Server: Apache/1.3.12 (Unix) Last-Modified: Tue, 17 Jul 2008 12:11:48 GMT ETag: "9ac90-d2f-39744984" Accept-Ranges: bytes Content-Length: 3375 Connection: close Content-Type: image/jpeg... Binäre Daten von einem JPEG-File (3375 Bytes)... 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-15 15. Das Hypertext Transfer Protokoll 15-16 Proxies (1) HTTP Kommunikation (14) 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. 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-17 15. Das Hypertext Transfer Protokoll 15-18 Proxies (2) Proxies (3) 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. 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-19 15. Das Hypertext Transfer Protokoll 15-20 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. 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-21 15. Das Hypertext Transfer Protokoll 15-22 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). 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-23 15. Das Hypertext Transfer Protokoll 15-24 Methoden (3) Syntax eines Response (1) 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. 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-25 15. Das Hypertext Transfer Protokoll 15-26 Status-Codes: Beispiele Overview 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. 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies) 15. Das Hypertext Transfer Protokoll 15-27 15. Das Hypertext Transfer Protokoll 15-28 Medientypen (1) Medientypen (2) 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. 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-29 15. Das Hypertext Transfer Protokoll 15-30 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. 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. model, z.b. model/vrml. 15. Das Hypertext Transfer Protokoll 15-31 15. Das Hypertext Transfer Protokoll 15-32 Alternative Versionen (1) 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-. 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-33 15. Das Hypertext Transfer Protokoll 15-34 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" 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-35 15. Das Hypertext Transfer Protokoll 15-36 Kompressions-Methoden Overview 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. 1. Requests and Responses 2. Content Negotiation 3. State Management (Cookies)
15. Das Hypertext Transfer Protokoll 15-37 15. Das Hypertext Transfer Protokoll 15-38 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. 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-39 15. Das Hypertext Transfer Protokoll 15-40 Cookies (2) Cookies (3) Ein Cookie kann z.b. eine User-Nummer oder eine Session-Nummer enthalten. Z.B. telnet www.altavista.com 80: 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; 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-41 15. Das Hypertext Transfer Protokoll 15-42 Private Probleme 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. 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.