1/39
JigsawDer Referenz-Server des W3C
Richard Cyganiak, 27. Mai 2003
Seminar “Webserver-Technologien”Prof. Robert TolksdorfFreie 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 (http://jigsaw.w3.org/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
http://example.org/icons/small/
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?.......
http://example.org/view?foo=barURLs
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
http://example.org/icons/small/
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 www.example.com 80
• Windows– putty.exe im Raw-Modus
24/39
Beispiel
GET /Protocols/ HTTP/1.1Host: www.w3.org
HTTP/1.1 200 OKDate: Mon, 26 May 2003 03:59:15 GMTServer: Apache/1.3.27 (Unix) PHP/4.2.3Cache-Control: max-age=21600Expires: Mon, 26 May 2003 09:59:15 GMTLast-Modified: Wed, 16 Apr 2003 09:19:33 GMTETag: "3e9d2025"Accept-Ranges: bytesContent-Length: 20975Content-Type: text/html; charset=iso-8859-1
<html>.....
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
– http://www.w3.org/Protocols/rfc2616/rfc2616.html
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 TimBL’s 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-8859-1, 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-8859-1, 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:http://www.w3.org/Jigsaw/
• Jigsaw Demo Site:http://jigsaw.w3.org/
• HTTP 1/1 Spezifikationhttp://www.w3.org/Protocols/rfc2616/rfc2616