HTTP – Hypertext Transfer Protocol Von Thomas Hilbert

HTTP - Hypertext Transfer Protocol Allgemeines Befehle Statuscodes Funktionsweise Protokollversionen Content Negotiation Authentifikation Caching-Strategien Cookies Ich werde euch die Funktionsweise der verschiedenen HTTP-Versionen vorstellen. Und anschließend die Begriffe „Content Negotiation“, „Authentifikation“ erklären. Zum Abschluss gehe ich noch auf die Caching- Strategien ein und erzähle etwas über Cookies

HTTP - Allgemeines HTTP wurde 1989 entwickelt. Es wird benutzt, um Webseiten in einem Browser darzustellen und um Daten zu übertragen. Im ISO/OSI und im TCP/IP Modell arbeitet es auf der höchsten Ebene (Anwendungsschicht). Das Hypertext-Transfer-Protokoll wurde 1989 zusammen mit URL und HTML entwickelt, wodurch praktisch das World-Wide-Web entstand. HTTP wird benutzt um Webseiten in einem Browser darzustellen und um Daten zwischen Server und Client zu übertragen. Im ISO/OSI und TCP/IP Modell arbeitet es auf der höchsten Schicht – was jeweils die Anwendungsebene ist.

HTTP - Befehle GET – Inhalte vom Server anfordern POST – wie GET, aber zusätzlich ein Datenblock HEAD – nur der Header wird gesendet (Gültigkeitsprüfung) PUT – Daten auf einen Server laden DELETE – Datei auf dem Server löschen Hier sind die wichtigsten Befehle des HTTP aufgelistet, wobei hauptsächlich mit GET gearbeitet wird. Mit GET und POST kann man Inhalte vom Server anfordern, wobei bei POST die zulässige Datenmenge größer ist. Mit dem Befehl HEAD wird nur der Header ohne Dateninhalt gesendet, was z.B. zur Gültigkeitsprüfung wichtig ist. Mit PUT kann man Daten auf den Server legen und mit DELETE die Daten dort löschen. Die befehle PUT und DELETE sind allerdings erst seit Version 1.1 verfügbar.

HTTP - Statuscodes Codes 1xx: Allgemeine Informationen 101 Switching Protocols Codes 2xx: Anfrage des Clients verstanden und erfüllt 200 OK Codes 3xx: Anfrage des Clients verstanden, jedoch nicht erfüllbar 301 Moved Permanently Codes 4xx: Anfrage des Clients unvollständig oder fehlerhaft 404 Not Found 408 Request Time-out Codes 5xx: Fehler im Server 504 Gateway Time-out Hier sind einige Code-Beispiele die ich kurz erklären möchte. Beginnt ein Code mit einer 1 dann werden allgemeine Informationen ausgetauscht, wie z.B. bei 101. hierbei wünscht der Client ein anderes Protokoll Codes die mit einer 2 anfangen wurden auf dem Server erkannt und erfüllt Beim Code 200 wurde die Anfrage erfolgreich erfüllt und die Datei liegt im Body bereit Codes im 3-hunderter Bereich wurden zwar verstanden, können aber nicht erfüllt werden So z.B. 301 – Moved Permanently. Hier bekommt der Client mitgeteilt dass die gewünschte Datei verschoben wurde und dass die neue Adresse das nächste mal benutzt werden soll. Dann gibt es noch die Codes die mit einer 4 beginnen und die wohl jeder schon mal kennen gelernt hat. Ganz bekannt ist z.B. die 404 Not Found für eine nicht gefundene Datei oder die 408 Request Time-out die anzeigt dass in der vorgegebenen zeit keine Abarbeitung der Anfrage möglich war. Ein lustiger Statuscode ist 424 – Site too ugly Hierbei übermittelt der Server die Seite aus ästhetischen gründen nicht (weil z.B. zu viele Frames enthalten sind oder die Seite in Bearbeitung ist) Codes mit einer 5 stellen Fehler im Server dar – so die Nummer 504 Gateway Time-out – hier konnte die anfrage an den gateway nicht rechtzeitig bearbeitet werden

HTTP - Funktionsweise Um die Seite „http://www.beispiel.de/index.html“ im Browser darzustellen, fragt HTTP den Host „www.beispiel.de“, ob dieser die Datei „index.html“ senden kann. Dabei wird der Host-Name mit Hilfe des DNS in eine IP-Adresse umgewandelt. Wenn man sich im Internet die Seite http://www.beispiel.de/index.html ansehen will wird durch das davorstehende „http“ eben dieses Protokoll verwendet um den Server zu kontaktieren. Bei der Anfrage wird erst einmal die www-Adresse in eine IP-Adresse umgewandelt. Dies geschieht über einen Domain Name Server (DNS). Dann kann das HTTP sich an die entsprechende Adresse wenden und die Seite „index.html“ anfordern.

HTTP – Beispiel Anfrage: GET /index.html HTTP/1.1 Host: www.beispiel.de Antwort: HTTP/1.1 200 OK Server: Apache/1.3.29 (Unix) PHP/4.3.4 Content-Length: 384575 Content-Language: de Content-Type: text/html (Inhalt der Datei) In diesem Beispiel fragt das Protokoll mit der Version 1.1 nach ob der Host „www.beispiel.de“ die Datei „index.html“ senden kann. Der Server antwortet mit der Nummer 200 – was bedeutet, dass die Anfrage erfolgreich bearbeitet wurde. Die genauen Daten vom Server und der Datei werden ebenfalls mitgesendet. So steht zum Beispiel in der Antwort was es für ein Server ist und welche Versionsnummer er besitzt. Außerdem natürlich noch Details zur gewünschten Datei. So z.B. die Länge der Datei in Byte angegeben, die Spracheinstellung falls es die Datei in verschiedenen Sprachen gibt und die Art der Datei. Im Anschluss kommt dann die gewünschte Datei.

HTTP - Protokollversionen Nach jeder Anfrage bzw. Antwort wurde die Verbindung beendet und jeweils ein Header mitgesendet. HTTP1.1 Hierbei wurde die persistente Verbindung eingeführt. D.h., es wird nur eine Verbindung benötigt, in der alle Anfragen/Antworten bearbeitet werden. Zusätzlich können abgebrochene Übertragungen fortgesetzt werden. Von HTTP gibt es zwei Versionen. Bei HTTP 1.0 wird bei jeder Anfrage und Antwort eine neue Verbindung erstellt bzw. eine alte Verbindung geschlossen und dazu jeweils einen eigenen Header gesendet. Dabei fielen natürlich überflüssige Datenmengen an, was bei langsamen Verbindung zu längeren Wartezeiten führte. Heute gibt es eine neuere Version 1.1, wobei sogenannte „persistente Verbindungen“ benutzt werden, bei denen eine Verbindung aufgebaut und erst nach Abschluss der kompletten Aufgabe wieder geschlossen wird. Hierbei fallen die ganzen erneuten Header und Kontrollblöcke weg und zusätzlich können abgebrochene Übertragungen wieder fortgesetzt werden.

HTTP – Content Negotiation Content Negotiation ist ein Verfahren, um die richtige Version aus der auf dem Server liegenden Dateien zu finden. z.B. Sprach- oder Kodierungs-Varianten Server-Driven CN (Server ist verantwortlich) Agent-Driven CN (Client ist verantwortlich) Transparent Negotiation (Kombination) Wenn von einer Datei verschiedene Varianten wie z.B. verschiedene Sprachen(deu, eng, fra), Kodierungen(ascii, binär), Qualität(low, mid, high) auf dem Server liegen, wird durch Content Negotiation die richtige Variante ausgewählt. Davon gibt es drei verschiedene Möglichkeiten: Server-Driven – der Server ist verantwortlich für die Auswahl Agent-Driven – der Client ist verantwortlich für die Auswahl oder Transparent Negotiation eine Kombination aus beidem über einen Proxy

HTTP - Authentifikation Wenn ein geschützter Pfad angefragt wird, sendet der Server mit 401 einen Fehler zurück und dazu einen www-Authentifizierungsheader. Nun kann der Client erneut anfragen und das benötigte Passwort mitschicken. Wenn eine Datei angefordert wird, auf die nicht jeder Zugriff haben soll, dann wird automatisch der Fehler 401 zusammen mit einem www- Authentifizierungsheader zurück an den Client geschickt. Dieser weiß nun, dass ein Passwort benötigt wird und kann dieses zusammen mit der erneuten Anfrage an den Server senden um Zugriff zu bekommen.

HTTP - Authentifikation Basic-Authentification Client will auf eine Datei zugreifen GET /download/index.html HTTP/1.1 Server antwortet mit Statuscode 401 HTTP/1.1 401 Authorization Required www-Authenticate: Basic realm=„Download“ Client antwortet jetzt mit dem erforderlichen User (admin) und Passwort (passwort) Authorization: Basic QWRtaW46cGFzc3dvcnQ= Die erste Möglichkeit der Authentifikation ist die Basic-Authentification. Zu Beginn fragt der Client ganz normal nach der gewünschten Datei. Da dies aber ein geschützter Bereich ist, wird zuerst der Statuscode 401 (Unauthorized) gesendet und dabei das Authentifizierungsverfahren genannt (hier Basic) Jetzt weiß der Client bescheid und sendet die gewünschten Daten erneut, wobei der Username und das Passwort mit base64 verschlüsselt sind. Dieses Verschlüsselungsverfahren ist jedoch nicht wirklich sicher.

HTTP - Authentifikation Digest-Access-Authentification Client will auf eine Datei zugreifen GET /download/index.html HTTP/1.1 Server antwortet mit Statuscode 401 HTTP/1.1 401 Authorization Required www-Authenticate: Digest realm=„Download“ nonce=„dcd98b7102dd2f0e8b11d0f600bfb0c093“ Client antwortet jetzt mit dem erforderlichen User und Passwort Authorization: Digest username=„admin“ nonce=„ dcd98b7102dd2f0e8b11d0f600bfb0c093“ response=„6629fae49393a05397450978507c4ef1“ Bei Digest-Access-Authentification sendet der Client ebenfalls ganz normal die Anfrage auf den geschützten Pfad. Zur Antwort des Servers wird jetzt allerdings noch ein nonce-String hinzugefügt, der immer zu einer 401-Antwort gehört und der in base64 verschlüsselt ist. Der nonce-String ist wieder derselbe wie in der 401-Antwort des Servers um festzustellen, dass diese Nachrichten zusammen gehören. Der response-String enthält einen 128-Bit-MD5-Hashwert aus User-ID, Passwort, dem nonce-Wert, der http-Methode und aus der URL. Der Server überprüft die Richtigkeit der Angaben indem er einen zweiten Hashwert erstellt und die beiden vergleicht. Da MD5 höchstens mit einen Großrechner, und dann auch nur mit großem Aufwand, geknackt werden kann ist es als Passwortschutz sicher.

HTTP – Caching Strategien Caching beim Client Temporäre Dateien Caching beim Server erteilte Antworten werden gespeichert Caching zwischen Server und Client Cache entscheidet Caching soll es ermöglichen, den Datenverkehr zwischen Server und Client so gering wie möglich zu halten, um die Daten schnell zustellen zu können. Außerdem wird jeweils die Lebenszeit der Datei überprüft, damit keine veralteten Daten gesendet werden, sondern nur die neuesten. Um Dateien zwischen Server und Client auszutauschen, gibt es verschiedene Caching-Strategien damit die Dateien schnell gesendet werden können. Caching beim Client bedeutet, dass der Client die benutzten Dateien temporär abspeichert um sie später schnell wieder aus dem eigenen Speicher aufrufen zu können und nicht erneut vom Server anfordern zu müssen. Als Beispiel wären die Temporären Internetdateien und die History vom Webbrowser. Beim Caching über den Server werden bereits erteilte Antworten im Cache gespeichert um gleiche Anfragen schneller wieder rauszuschicken. Um Caching zwischen Server und Client nutzen zu können muss der Client entsprechend konfiguriert sein. Hierbei entscheidet der Cache selber ob er die vorhandene datei sendet (falls er sie hat) oder eine neuere vom Server anfordert.

HTTP - Cookies Vorteile: Nachteile: Benutzerdaten bleiben erhalten Standardeinstellungen bleiben erhalten Warenkorb wird ermöglicht Nachteile: Ausspionieren der Surfdaten Persönliche Daten können weiterverkauft werden Spam-Mails können ermöglicht werden Cookies sind kleine Dateien, die es erlauben Daten von einem Server auf dem Client zu speichern. Sie sollen es dem Benutzer erleichtern im Internet unterwegs zu sein. So können z.B. die Benutzerdaten oder Einstellungen gespeichert werden um diese nicht bei jedem Besuch neu eingeben zu müssen. Außerdem konnte so ein Warenkorb in Webshops einfach realisiert werden. Leider können Cookies auch missbraucht werden, um die Surfdaten der Besucher auszuspionieren und eventuell sogar weiter zu verkaufen. Manche Betreiber von Webpages erlauben anderen Unternehmen die Platzierung von Cookies auf den Rechnern der Kunden. Z.B. erlaubt Yahoo seinen Werbepartnern die gesammelten Daten zu benutzen. Diese Partner können die Daten dann beliebig benutzen .(man muss sich dort also nicht über unnötig viel Spam wundern)

HTTP - Cookies # Netscape HTTP Cookie File # http://www.netscape.com/newsref/std/cookie_spec.html # This is a generated file! Do not edit. .disney.com TRUE / FALSE 946684799 DISNEY 194.42.212.24526008849568741758 .nrsite.com TRUE / FALSE 946598400 NRid haaTwLty28uoFDrQWOwrlW metacrawler.cs.washington.edu:8080 FALSE / FALSE 942189160 nbfp2 1101 www.info.de FALSE / FALSE 942189160 Apache zimbo12480852509200442 www.noris.de FALSE / FALSE 942189160 Apache zimbo529785259903010 .netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 1000e010,106b6f55 Dies ist ein Beispiel einer Cookie-Datei. Jede Zeile steht für einen Datenblock von je einer Seite. Am Anfang steht zuerst die Herkunft um den Cookie später wieder zuordnen zu können. dahinter wird angegeben ob der Cookie gesetzt ist und nach wievielen Sekunden er abläuft. Danach stehen weitere Informationen die dieWebseite dann verarbeiten kann. So kann dort z.B. eine IP-Adresse, ein Benutzername oder eine Emailadresse verschlüsselt hinterlegt sein. Wenn man nun eine Information löschen möchte, leert man am besten die komplette Zeile. Besser ist natürlich die Funktion im Browser zu nutzen. Je nach Browser kann man einzelne Cookies oder alle löschen. Über die Browsereinstellung kann man die Cookies je nach badarf zulassen oder verweigern um sich sicher und trotzdem bequem im Internet zu bewegen. Bei neuen Browserversionen kann man dies sogar für jede einzelne Seite einstellen wie z.B. bei Opera.

Quellenangaben www.wikipedia.de www.www-kurs.de/cookies.htm www.informatik.uni-trier.de www.google.de