5. Übungblatt UNIX Praktikum

swebd: Prozesskommunikation, Sockets, Libraries, TCP/IP
Abgabe: 16. Juli 2006

Es soll ein einfacher Web-Server implementiert werden, der ein beim Aufruf übergebenes Verzeichnis auf einen frei wählbaren Port per HTTP-Protokoll exportiert. Folgende Features soll der Server beherrschen:

Als Client sollen beliebige Browser verwendet werden können, also müssen alle zwingend erforderlichen Header-Felder übermittelt werden. Nicht unterstützte Features soll der Server protokollgemäß ablehnen.
Der Server soll nur die beim Start übergebenen Dateien und Verzeichnisse exportieren. Die Liste aller gültigen Dokumente soll einmal eingelesen werden und Anfragen dann mit dieser Liste verglichen werden. Verzeichnisse sollen rekursiv behandelt werden, d.h. es müssen alle Dateien in diesen Verzeichnissen in die Liste aufgenommen werden.
Wird dem Server als URI der Name eines Verzeichnisses übermittelt, so soll der Server den Inhalt des Verzeichnisses (mit Links) in einem im Anhang beschriebenen Format darstellen.
Sofern der Client gzip- oder deflate-komprimierte Übermittlung unterstützt und anfordert, soll der Server dies auch erfüllen. Verwendet dazu die Bibliothek zlib. Details dazu siehe Anhang.
Clients sollen Dateien auf den Server hochladen können. Dazu soll sich der HTTP-Methode PUT bedient werden. Dateien sollen nur in einem vom Benutzer angegebenen Verzeichnis gespeichert werden. Zusätzlich soll ein Client programmiert werden, der das Hochladen einer Datei auf einfache Art und Weise ermöglicht (siehe Beschreibung Client).
Der Server soll auf einem zusätzlichen Admin-Port lauschen und von dort administrative Befehle entgegennehmen. Dabei schickt ein Client einfach die Kommandos STATUS, SHUTDOWN, ABORT, REREAD oder LIST ohne weitere Parameter mit einem Zeilenendezeichen (CR oder LF) an den Serverport, der Server soll dann entsprechend reagieren. Details dazu siehe Beschreibung Admin-Protokoll.
Offensichtlich erfordert dieser Admin-Port eine Art von Authentisierung. Macht euch Gedanken, was mit welchen Aufwand möglich wäre und dokumentiert kurz Vor- und Nachteile der einzelnen Verfahren (mindestens drei). Implementiert dann eines dieser Verfahren in euren Server.
Der Server soll auf Signale reagieren. Dabei bilden die einzelnen Signale SIGINT, SIGQUIT und SIGHUP auf die auf über den Admin-Port beschriebenen Funktionen SHUTDOWN, ABORT und REREAD ab.
Der Server soll die korrekten MIME-Types für die übertragende Datei übermitteln. Der Typ einer Datei ist aus deren Endung (alles nach dem letzten Punkt im Dateinamen) zu entnehmen. Verwendet dazu das zur Verfügung gestellte Modul mime_types.[ch].

Folgende Kommandozeilenoptionen soll der Server beherrschen:

swebd [-h|-?] [-dv]
      [-i ] [-p ] [-a ]
      /lehre/unix/ss06/swebd.html| [/lehre/unix/ss06/swebd.html|] ...

-h|-?: Auflisten aller gültigen Optionen (Hilfe)
-d: Loslösen vom Terminal nach Beginn des Programms (daemonize)
-i <Verzeichnis>: Benutze <Verzeichnis> für hochgeladene Dateien
-p <port>: Lausche auf TCP-Port <port> (Standard: 8080)
-a <port>: Benutze den TCP-Port <port> als Admin-Port. Sollte diese Option nicht angegeben werden, so ist der Admin-Port zu deaktiveren.
-v: Gebe Diagnosemeldungen auf stdout aus.

HTTP-Protkoll

Das HTTP-Protokoll ist im RFC 2068 beschrieben. Der Server soll eine Untermenge dieses Protokolls verstehen und bearbeiten, allerdings ist dabei auf vollständige Kompatiblität zu Clients zu achten, d.h. nicht implementierte Operationen sind protokollgemäß abzulehnen. Obligatorische Felder sind in jedem Fall zu implementieren. Im folgenden folgt hier eine einfache Zusammenfassung des Protokolls:

Der Client baut die Verbindung per TCP zum Server auf und schickt seine Anfrage (Request) auf mehrere Zeilen verteilt zum Server. Die erste Zeile hat dabei folgendes Format: <REQ> (Leerzeichen) <URI> (Leerzeichen) <Version> (CRLF). Dabei bezeichnet REQ den Request-Typ (GET, HEAD oder PUT), URI ist die gewünschte Adresse und Version bezeichnet die verwendete HTTP-Version. Browser tragen hier üblicherweise HTTP/1.0 oder HTTP/1.1 ein, der Server soll die Protokoll-Version 1.1 verstehen können. Nach diesen Zeilen folgen Message-Header, die weitere Parameter oder Optionen zu dieser Anfrage beinhalten. Diese Header-Felder sind durch ihren Namen gefolgt von einem Doppelpunkt und den nachfolgenden Inhalt gekennzeichnet (ähnlich dem E-Mail-Format). Ein Message-Header wird durch die Zeilenende-Zeichen CRLF=\r\n abgeschlossen. In dieser Weise folgen mehrere Message-Header, deren Ende dann durch eine leere Zeile angezeigt wird. Die einfachste Anfrage nach HTTP/1.1-Protokoll kann so aussehen:

		GET /index.html HTTP/1.1
		Host: localhost

Ein typische Anfrage eines richtigen Browsers sieht z.B. so aus:

		GET /index.html HTTP/1.1
		User-Agent: Opera/8.51 (X11; Linux i686; U; de)
		Host: localhost:4711
		Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, ...
		Accept-Language: de,en;q=0.9,ru;q=0.8
		Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
		Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
		Connection: Keep-Alive

Header-Felder, die der Server bei einer Response liefern muß, sind: Content-Type, Content-Encoding und Content-Length. Andere Felder können optional implementiert werden. Insbesondere Sinn macht hier die Unterstützung von abgebrochenen Downloads, in dem die Header-Felder Range, Content-Range und Accept-Range ausgewertet und bearbeitet werden. Eine Implementation dieses Features wirkt sich positiv auf die Rücksprache aus!

Bei Unklarheiten kann man sich einfach mit dem Tool netcat (aufzurufen mit nc, installiert in /home/pub/bin) die Anfrage eines Browsers oder die Reaktion eines Servers anzeigen lassen.

Komprimierte Übertragung

Ein Browser kann eine on-the-fly Komprimierung der übertragenden Daten anforden. Dazu sendet er im Accept-Encoding Header-Feld die Namen der von ihm unterstützten Verfahren. Der Server zeigt dann die Verwendung eines dieser Verfahren durch die Nennung im Feld Content-Encoding an.

Der Server soll in unserem Fall die Typen deflate, gzip und x-gzip unterstützen. Die letzten beiden Typen sind dabei effektiv dasselbe, als würde man die Datei vorher mit gzip komprimieren. Zum Testen könnt ihr daher für gzip das externe Kommando gzip in die Ausgabe einschleifen.

Das deflate-Format ist die Basis von gzip, wird allerdings von gzip nicht direkt als Ausgabeformat unterstützt. Zur Unterstützung dieses Formats ist es daher nötig, die zlib-Bibliothek zu verwenden. Die nötige Dokumentation dazu findet ihr in der Header-Datei zlib.h. Es ist sinnvoll, die Kompression in einen Kind-Prozeß auszulagern, so kann man den Code stark vereinfachen. Zum Durchschleifen der Ausgabe könnt ihr dann die Pipeline-Mechanismen aus der Shell-Aufgabe verwenden. Wenn die Komprimierung benutzt wird, braucht das Header-Feld Content-Length nicht gesetzt zu sein.

PUT-Feature

In der HTTP/1.1-Version findet sich ein Verb für das einfache Hochladen von Daten zu einer URL. Dabei wird die Methode PUT benutzt, ansonsten ist die Syntax identisch mit der GET-Methode. Nach dem Ende des Headers sendet der Client die eigentlichen Daten ohne weitere Umkodierung. Um Sicherheitsproblemen vorzubeugen, ist von der URI nur der Dateiname zu benutzen, d.h. der Teil nach dem letzten Slash. Die gesendeten Daten sollen dann in einer Datei mit diesen Namen unter dem beim Start angegebenen Verzeichnis angelegt werden.

HTML für Verzeichnisse

Wenn dem Server der Name eines gültigen Verzeichnisses übergeben wird, dann soll der Server den Inhalt dieses Verzeichnisses im HTML-Format an den Browser übermitteln. Ihr könnt dabei folgendes Grundgerüst verwenden:

<html><head><title>Directory content - Name des Verzeichnisses</title></head>
<body>
<table border="0">
<tr><th>Name</th><th>Type</th><th>Size</th><th>Time</th></tr>
<tr><td>foobar</td><td>directory</td><td> </td>
    <td>2006-05-29 12:35:26</td></tr>
<tr><td>baz.bar</td><td>BAR file</td><td>27304 Bytes</td>
    <td>2006-05-29 12:37:10</td></tr>
<tr><td>vl1.pdf</td><td>application/pdf</td><td>185618 Bytes</td>
    <td>2006-04-21 23:56:14</td></tr>
</table>
</body>
</html>

Der Name des Verzeichnisses ist dabei im title-Tag einzusetzen. Gerne dürft ihr das Ausgabeformat verändern, solange mindestens die oben angegebenen vier Felder vorhanden sind. Im Feld ''Type'' soll entweder (sofern vorhanden) der MIME-Typ der Datei eingetragen werden oder die Endung des Dateinames mit dem Zusatz '' file'' (siehe Beispiel).

Client

Um die Funktionalität des Hochladens nutzen zu können, soll ein spezieller Client entwickelt werden. Dieser Client kann eine oder mehrere Dateien per HTTP-PUT (Version 1.1) an den Server übermitteln. Dabei sollen sowohl die Server-Adresse als auch die Dateien als Parameter übergeben werden. Dabei ist die Server-Adresse stets der erste Parameter: $ putclient localhost:8080 foo.bar *.txt Es reicht aus, wenn der Client mit dem Server zusammenarbeit.

Admin-Protokoll

Der Server soll auf einem frei wählbaren Admin-Port kurze Kommandos entgegennehmen. Dabei sollen folgende Features implementiert werden:

STATUS: liefert den Status des Servers (running, shutdown) sowie die Zahl der geraden aktiven Verbindungen (Kinder).
SHUTDOWN: beendet die Verbindungsannahme neuer Verbindungen und wartet, bis alle aktiven Verbindungen (aka. Kinder) beendet sind. Danach wird auch der Vaterprozess beendet.
ABORT: beendet den Server sofort, ohne auf die Kinder zu warten.
REREAD: die Liste der gültigen Dateien soll erneut eingelesen werden. Dabei sind die beim Start angegebenen Verzeichnisse erneut zu durchsuchen.
LIST: die Liste der gültigen Dateien soll ausgegeben werden.

Ein Client schickt eines dieser Kommandos und schließt die Eingabe mit dem HTTP-Zeilenendezeichen CRLF ab. Der Server antwortet dann über die TCP-Verbindung mit den Daten (STATUS, LIST) oder einem OK (SHUTDOWN, ABORT, REREAD) und beendet danach die Verbindung.

Hinweise

Interessante man-pages: select(3c), poll(3c), listen(3c), bind(3c), accept(3c), connect(3c), readdir(2), stat(2), mmap(2), fwrite(3), netcat(/home/pub/man,1)
Da das HTTP-Protokoll zeilenorientiert arbeitet, bieten sich für die Verarbeitung von Anfragen und Headern die gepufferten libc-Funktionen (fprintf, fgets, fread, fwrite) an. Ihr könnt einen Socket-Deskriptor mit fdopen(3) in eine FILE-Struktur überführen.
Die Vorgabe für die Ermittlung der MIME-Types steht in eurem CVS-Repository bereit. Die Dokumentation dazu ist in der Header-Datei zu finden.
Lest im Zweifel auch das RFC 2068 zum HTTP-Protokoll.
Benutzt als Client zum Testen nc oder wget, da hier im Fehlerfall mehr Meldungen ausgegeben werden.
Fangt rechtzeitig an! Die einzelnen Teil-Aufgaben sind an sich nicht schwierig, der Teufel steckt aber manchmal in den Details.