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