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

Präsentation zum Thema: "1/39 Jigsaw Der Referenz-Server des W3C Richard Cyganiak, 27. Mai 2003 Seminar Webserver-Technologien Prof. Robert Tolksdorf Freie Universität Berlin,"—  Präsentation transkript:

1 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 2/39 Inhalt Jigsaw –Allgemeines –Architektur HTTP –PUT –Content Negotiation –Transfer encodings

3 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 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 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 6/39 Testplattform HTTP/1.1 HTTP-NG Servlets PICS WebDAV CC/PP Photo RDF

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

8 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 9/39 Dateisystem http://example.org/icons/small/ URLs 1:1 mod_rewrite Dateisystem-orientierte Server 1:1-Abbildung von URLs auf Dateien

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

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

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

13 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 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 15/39 Filter Verändern Ressourcen (Anfrage und/oder Antwort) An Frame gebunden, da meist protokollspezifisch Beispiele: –AuthFilter –GzipFilter –CounterFilter –LogFilter –TidyPutFilter –HourLimiterFilter

16 16/39 Demo

17 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 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 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 20/39 Jigsaw: Zusammenfassung Plattform zum Experimentieren Flexibel und erweiterbar Vollständig objektorientiert Administrationstool Vollständige HTTP/1.1-Implementierung

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

22 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 23/39 HTTP ausprobieren Unix –telnet www.example.com 80 Windows –putty.exe im Raw-Modus

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

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

26 26/39 Status Codes 200 OK 404 Not Found 400 Bad Request und viele andere –http://www.w3.org/Protocols/rfc2616/rfc2616.htmlhttp://www.w3.org/Protocols/rfc2616/rfc2616.html

27 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 28/39 Anwendungen für PUT Sehr praktisch für das Bearbeiten von Webseiten –Mozilla, Amaya Zusammen mit WebDAV: Netzwerk-Dateisystem

29 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 30/39 Accept*-Header Accept (z.B. text/html) Accept-Language (z.B. de) Accept-Charset (z.B. ISO-8859-1, utf-8) Accept-Encoding (z.B. gzip, chunked)

31 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-8859-1, utf-8;q=0.66, *;q=0.66

32 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 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 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 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 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 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 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/39 Quellen Jigsaw Website: http://www.w3.org/Jigsaw/ http://www.w3.org/Jigsaw/ Jigsaw Demo Site: http://jigsaw.w3.org/ http://jigsaw.w3.org/ HTTP 1/1 Spezifikation http://www.w3.org/Protocols/rfc2616/rfc2616 http://www.w3.org/Protocols/rfc2616/rfc2616