Ein Vortrag aus der Reihe inf.misc 8. Juni 2005 50. Geburtstag von Tim Berners-Lee
Inhalt 1 2 3 Content Negotiation Caching Authentifizierung 4
Definition RFC 2616, Abstract: The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext. [...] A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. OSI-Schicht 7/TCP-Schicht 4 (Applikationsschicht) vollständig und verbindlich in RFC 2616 definiert
Geschichte 1990: erste Version (HTTP/0.9): einfache Datenübertragung über TCP/IP 1996: grundlegende Überarbeitung (HTTP/1.0): Übertragung der Metadaten, kleine Unzulänglichkeiten, großes Wirrwarr 1997: neue Versionsnummer (HTTP/1.1): kleinere Verbesserungen, strengere Anforderungen, Stabilisierung 1999: letzter Schliff für HTTP/1.1: RFC 2616, heutiger Standard
Grober Überblick Client-Server-Dialog: 2: +Data Server Client 1:
HTTP-URLs Syntax http://hostname:port/path/to/resource?q1 =v1&q2 =v2&... Beispiele http://localhost/index.html http://www.google.com/search?q=http&start=0 keine Längenbeschränkung im Standard selbst de-facto Beschränkung von 2083 Zeichen durch M$IE
Header Syntax Hauptmittel zur ssteuerung Anweisungen bzw. Empfehlungen zur Datenbehandlung (z.b. Caching) Metadaten (z.b. Datentyp) Name: Value <CR><LF> Beispiele Host: www.informatik.uni-stuttgart.de User-Agent: Mozilla/5.0 Content-Type: image/png
Interaktion Client-Server-Dialog: 2: +Data Server Client 1:
Interaktion mal anders Mensch-Kaffeemaschine-Dialog 2: Antwort+Kaffee Kaffeeautomat Mensch 1: Bestellung
GET-s Ein Kaffee, bitte! Minimalbeispiel GET /index.html HTTP/1.1 Host: fachschaft.informatik.uni-stuttgart.de der wohl meistverwendete einfache Informationsanforderung Parameterübergabe im URL-Text: Beispiel mit Parameterübergabe GET /search?q=inf.misc HTTP/1.1 Host: google.de Referer: http://fachschaft.informatik.uni-stuttgart.de/index.html
HEAD-s Ist denn überhaupt Kaffee da? Minimalbeispiel HEAD /index.html HTTP/1.1 Host: fachschaft.informatik.uni-stuttgart.de das gleiche wie GET, allerdings werden keine Daten als Antwort erwartet Testrequest Handwerkszeug aller (vernünftigen) Link-Checker usw.
POST-s Hier sind Milch und Zucker, tu die in meinen Kaffee rein! Beispiel POST /index.php HTTP/1.1 Host: www.kaffeemaschine.local Content-Type: application/x-www-form-urlencoded Content-Length: 36 zucker=wuerfel1wuerfel2&milch=keine wird benutzt, um Daten an den Server zu übertragen flexibler als GET und nicht längenbeschränkt es können auch Dateien angehängt werden
Die Serverantwort besteht aus 3 Teilen: 1 eine Kopfzeile mit dem Antwortcode (Error Code) 2 Header zur Beschreibung des Inhalts 3 Nutzdaten Beispiel HTTP/1.x 302 OK Date: Sun, 05 Jun 2005 22:34:36 GMT Content-Type: text/html; charset=utf-8 <html><head>...
2xx Successful Hier ist dein Kaffee. 200 OK: Die Anfrage war erfolgreich, die Daten werden übermittelt 203 No Content: Die Anfrage war erfolgreich, keine Daten zum Senden 206 Partial Content: Die Anfrage war erfolgreich, das angeforderte Datenstück wird übermittelt
3xx Redirection Kaffee gibt s da drüben. 301 Moved Permanently: Die Ressource wurde verschoben und ist ab sofort unter einer anderen Adresse zu erreichen. 302 Found: Die Ressource wurde gefunden, aber ist eitweilig unter einer einer anderen Adresse zu erreichen. 304 Not Modified: Der Inhalt der Ressource wurde im fraglichen Zeitraum nicht verändert.
4xx Client Error Du bist blöd und kriegst hier keinen Kaffee! 400 Bad : der ist fehlerhaft. 401 Unauthorized: bitte noch einmal mit Authorisierung versuchen! 403 Forbidden: hier hilft auch keine Authorisierung. 404 Not Found: ist selbsterklärend ;-) 410 Gone: nicht gefunden und wird auch nie wiederkommen. Leider unbenutzt.
5xx Server Error Hilfe, ich explodiere!! 500 Internal Server Error: Exception in der Server-Software. 503 Service Unavailable: Dienst zeitweise abgeschaltet wegen Überlastung oder Wartungsarbeiten.
Content Negotiation Content Negotiation Caching Authentifizierung Kaffeespezialitätenproblem Ich hätte gern ein Cappuccino, aber wenn du keinen hast, gib mir einen Kaffee mit Milch, und wenn du keine Milch hast, dann einen mit Zucker und zu allergrößter Not gebe ich mich mit einem Tee zufrieden. HTTP ist auf größtmögliche Portabilität ausgelegt die Information liegt oft in verschiedenen Repräsentationen vor (Text, Bild, verschiedene Sprachen, verschiedene Zeichensätze...) HTTP stellt Hilfsmittel bereit, um die bestmögliche Variante transparent auszuwählen
Accept, Accept-Charset Content Negotiation Caching Authentifizierung Accept-Header Accept: application/pdf, application/xhtml+xml; q=0.7, text/plain; q=0.2, text/html; q=0.5, application/msword; q=0 Accept-Charset: utf-8, iso-8859-5; q=0.9 ergibt folgende Präzedenz: 1 application/pdf (PDF) 2 application/xhtml+xml (XHTML) in UTF-8, dann in ISO-8859-5 3 text/html (HTML), Kodierung analog zu XHTML 4 text/plain (normaler Text), Kodierung analog zu XHTML 5 application/msword (M$ Word) niemals wegen q=0!
Accept-* Header im Überblick Content Negotiation Caching Authentifizierung Accept: Datentyp (MIME, z.b. text/plain) Accept-Charset: Zeichensatz (IANA Character Set Code, z.b. utf-8) Accept-Encoding: Datenkompression (z.b. gzip) Accept-Language: Sprache (IANA Language Tags/ISO 639, z.b. de-de) Accept-Range: Teil der Ressourcen (z.b. Byte 1056 bis 2567)
Caching Content Negotiation Caching Authentifizierung Caching ist ein Mittel, um den Netzverkehr in Grenzen zu halten Proxy vs. Client-Caching wichtige HTTP-Header Cache-Control: serverseitig, Anweisungen an den Client Expire: serverseitig, gibt an, wann die Ressource verdirbt If-[Un]Modified-Since: clientseitig, conditional Last-Modified: Information über das Alter der Ressource
Authentifizierung Content Negotiation Caching Authentifizierung HTTP definiert eine einfache Authentifizierung mit Benutzername und Passwort. Diese ist jedoch für die meisten Fälle zu einfach. Basic Authentication Benutzername und Passwort werden im Klartext übertragen Deswegen in kritischen Umgebungen nur mit SSL verwenden! Digest Authentication Benutzernamen und Passwort werden in einem MD5-Hash übertragen etwas sicherer, aber ebenfalls mit mehreren Schwachstellen nicht weit verbreitet Details sind in RFC 2617 beschrieben.
Header senden PHP: <?php header("content-type: text/plain"); echo "Hello World!";?> Perl: #!/usr/bin/perl -w my $Text = "Hello World"; print "Content-type: text/plain\n\n"; print $Text;
HTTP-Header abfangen Live HTTP Headers für Mozilla/Firefox: oder mit einem x-beliebigen Sniffer wie Ethereal
Links HTTP-Spezifikation: http://www.faqs.org/rfcs/rfc2616.html HTTP-Authentifizierung: http://www.faqs.org/rfcs/rfc2617.html Zeichensätze: http://www.iana.org/assignments/character-sets MIME-Datentypen: http://www.iana.org/assignments/media-types Sprachen (IANA): http://www.iana.org/assignments/language-tags Sprachen (ISO): http://en.wikipedia.org/wiki/iso_639 Live HTTP Headers http://livehttpheaders.mozdev.org/ Der Netzwerk-Sniffer: http://www.ethereal.com/