1/39 Jigsaw Der Referenz-Server des W3C Richard Cyganiak, 27. Mai 2003 Seminar Webserver-Technologien Prof. Robert Tolksdorf Freie Universität Berlin, Institut für Informatik

2/39 Inhalt Jigsaw –Allgemeines –Architektur HTTP –PUT –Content Negotiation –Transfer encodings

3/39 Teil 1: Jigsaw Referenz-Webserver des W3C Open Source, Java begonnen 1996 Entwicklung hauptsächlich am INRIA –Leiter: Yves Lafon vollständige HTTP/1.1-Implementierung Distributionen: Webserver, Proxy, WebDAV Jigsaw engl. Puzzle, Puzzlestück

4/39 Referenz-Server Plattform zum Experimentieren für Forscher –Lesbarer Code –Ausführlich dokumentierte APIs –Programmierhandbuch wichtiger als Benutzerhandbuch Flexibilität und Erweiterbarkeit wichtiger als Produktionstauglichkeit Java: Portabilität, Erweiterbarkeit

5/39 Einige Highlights Exportiert Objekte, nicht Dateien Multi-Protokoll-Server Push- und Streaming-Protokolle Unterstützt kollaborative Arbeit (PUT, CVS) Administrationstool JigAdmin Gute Performance dank minimierter Dateizugriffe und intelligentem Caching Moderne Architektur (1996)

6/39 Testplattform HTTP/1.1 HTTP-NG Servlets PICS WebDAV CC/PP Photo RDF

7/39 Jigsaw in der Produktion jigsaw.w3.org –Jigsaw-Demonstration –HTTP/1.1-Demonstration –CSS-Validator ( lists.w3.org –Archiv für alle Mailinglisten des W3C Sonst nichts?

8/39 Architektur Herkömmliche Webserver-Architekturen Jigsaw: Java-Objekte statt Dateien exportieren –Resource: ein zu exportierendes Objekt –Frame: veröffentlicht Resource für bestimmtes Protokoll –Filter: verändert Resources –Indexer: erzeugt automatisch Resources, Frames, Filters Vor- und Nachteile

9/39 Dateisystem URLs 1:1 mod_rewrite Dateisystem-orientierte Server 1:1-Abbildung von URLs auf Dateien

10/39 Servlet-Container Handkonfigurierte Abbildung von großen URL- Räumen auf einzelne Servlets PHP manchmal ähnlich org.example.servlet1 /view? URLs org.example.servlet2 /edit?

11/39 Object-Publishing Server Webserver exportiert Objekte Ein Objekt verantwortlich für GET, POST, PUT, Administrationsdienste einer URL Jigsaw, Zope URLs 1:1 Objekte

12/39 Jigsaw: Ressourcen Von Jigsaw exportierte Objekte heißen Ressourcen Beispielklassen: –FileResource –ServletWrapper –CvsRootDirectory –ZipFileResource –PasswordEditor –(CGI, Proxy) Ressourcen sind persistent

13/39 Ressourcenerzeugung: Indexer Manuell über JigAdmin Automatisch über Indexer –default-indexer –servlet-indexer –zip-indexer Indexer erzeugen und konfigurieren Ressourcen –z.B. Content-Type und Max-Age setzen in Abhängigkeit vom Dateityp Indexing-Phase

14/39 Ressourcen exportieren: Frames Ressourcen haben assoziierte Frames Frames veröffentlichen Ressourcen über ein bestimmtes Protokoll –HTTPFrame –PostableFrame –RelocatedFrame –DAVFrame Mitgeliefert: HTTP, WebDAV, CC/PP

15/39 Filter Verändern Ressourcen (Anfrage und/oder Antwort) An Frame gebunden, da meist protokollspezifisch Beispiele: –AuthFilter –GzipFilter –CounterFilter –LogFilter –TidyPutFilter –HourLimiterFilter

16/39 Demo

17/39 Vorteile Resource-Objekt kümmert sich um alle Arten von Anfragen an eine URL Filter ermöglichen flexible Konfiguration Trennung zwischen Ressourcen und Protokollmechanik Server für mehrere Protokolle möglich

18/39 Nachteile Administrationsaufwand durch Indexer Fehleranfälligkeit durch vollständige Serialisierung Zuständigkeitsverteilung zwischen Ressourcen und Frames oft unklar Sinn der Multiprotokollfähigkeit, wenn man nur HTTP will?

19/39 Subjektive Bemerkungen Coding Standards! Dokumentation –Superwichtig: Beschreibung der Funktion von Klassen –Superwichtig: gut dokumentierte Interfaces für wichtige Konzepte Vermeide Tangled Hierarchy –AttributeHolder als Oberklasse für fast alles –Folge: grundlegende Konzepte sind komplexe Klassen mit viel geerbtem Verhalten

20/39 Jigsaw: Zusammenfassung Plattform zum Experimentieren Flexibel und erweiterbar Vollständig objektorientiert Administrationstool Vollständige HTTP/1.1-Implementierung

21/39 Teil 2: HTTP PUT Content Negotiation Transfer Encodings

22/39 HTTP in 5 Minuten Textprotokoll Anfrage/Antwort Anfrage besteht aus –Request Line (Method, URL, HTTP-Version) –Reuest Headern –(Request Entity) Antwort besteht aus –Response Line (Status Code) –Response Headern –Response Entity

23/39 HTTP ausprobieren Unix –telnet 80 Windows –putty.exe im Raw-Modus

24/39 Beispiel GET /Protocols/ HTTP/1.1 Host: HTTP/ OK Date: Mon, 26 May :59:15 GMT Server: Apache/ (Unix) PHP/4.2.3 Cache-Control: max-age=21600 Expires: Mon, 26 May :59:15 GMT Last-Modified: Wed, 16 Apr :19:33 GMT ETag: "3e9d2025" Accept-Ranges: bytes Content-Length: Content-Type: text/html; charset=iso

25/39 HTTP Methoden GET POST HEAD PUT DELETE OPTIONS TRACE

26/39 Status Codes 200 OK 404 Not Found 400 Bad Request und viele andere –

27/39 Die PUT-Methode Lege Request-Entity unter der angegebenen URL ab Von Servern selten angeboten Apache –Skript festlegen, welches PUT-Anfragen behandelt –oder mod_put nachrüsten Hat schon in TimBLs ersten Browser gefehlt

28/39 Anwendungen für PUT Sehr praktisch für das Bearbeiten von Webseiten –Mozilla, Amaya Zusammen mit WebDAV: Netzwerk-Dateisystem

29/39 Content Negotiation Ressource ist in mehreren Sprachen oder Dateiformaten verfügbar Klient und Server handeln beste Variante aus Serverseitige Content Negotiation –Server entscheidet über beste Variante –Klient kann mit Accept*-Headern helfen Klientseitige Content Negotiation –Server liefert Liste mit allen Möglichkeiten als HTML –Klient entscheidet (manuell oder automatisch)

30/39 Accept*-Header Accept (z.B. text/html) Accept-Language (z.B. de) Accept-Charset (z.B. ISO , utf-8) Accept-Encoding (z.B. gzip, chunked)

31/39 ConNeg-Beispiel (1) Accept: text/xml,application/xml, application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,video/x-mng, image/png,image/jpeg,image/gif;q=0.2, text/css,*/*;q=0.1 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO , utf-8;q=0.66, *;q=0.66

32/39 ConNeg-Beispiel (2) Ressource ist in zwei Sprachen verfügbar –de;q=1.0 –en;q=0.33 Accept-Language: en –bekommt englisch Accept-Language: en;q=1.0, de;q=0.5 –bekommt deutsch Accept-Language: en;q=1.0, de;q=0.2 –bekommt englisch

33/39 Anwendungen für ConNeg Sprache auswählen Theoretisch: Klient und Server verhandeln über optimales Format Senden von XHTML 1.1 and gute Browser Web Services nach der REST-Architektur Semantic Web (Accept: application/rdf+xml)

34/39 Encodings Content-Encodings (Codierung der Entität) –gzip (GNU zip) –compress (LZW) –deflate –identity (nur für Accept-Encoding) –... Transfer-Encodings (Codierung der Nachricht) –chunked –gzip –...

35/39 Exkurs: Ein Problem bei dynamischen Inhalten Werte einiger Header erst spät bekannt –Last-Modified, Cookie, Location kann erst Inhalt schicken, wenn alle Header feststehen –Alle Header vor Sendung des ersten Bytes ermitteln –Oder gesamte Ausgabe puffern Wäre schön: optional weitere Header am Ende der Datei verschicken Problem: Woher weiß Klient, wo Inhalt zu Ende ist?

36/39 Transfer-Encoding: chunked Sende: 1. Kopf mit Headern 2. Inhalt blockweise mit Längenangaben für jeden Block 3. Optional weitere Headerzeilen (Trailer) Unterstützung für HTTP/1.1-Klienten Pflicht Zustellung des Trailers kann wegen HTTP/1.0- Klienten nicht garantiert werden

37/39 Anwendungen für Encodings gzip –Wenn CPU-Zyklen billig und Transfervolumen teuer –Proxies chunked –Wenn Länge der Nachricht zu Beginn unbekannt –dynamische Inhalte mit Trailer oder Keep-Alive

38/39 HTTP: Zusammenfassung PUT –Praktische Methode zum Bearbeiten von Web-Inhalten –Von wenigen Servern unterstützt Content Negotiation –Automatische Auswahl von Sprache oder Format –Fähigkeiten des Klienten und Benutzereinstellungen Encodings –Komprimieren des Datenstroms mit gzip –Stückweises Senden mit chunked, wenn Gesamtgröße unbekannt

39/39 Quellen Jigsaw Website: Jigsaw Demo Site: HTTP 1/1 Spezifikation