WWWOFFLE Version 2.6d "FAQ" (Häufig gestellte Fragen und Antworten)

Dieses Dokument enthält eine Liste von häufig über WWWOFFLE 2.6d gestellten Fragen und passende Antworten dazu.

Nicht alle hier gestellten Fragen sind "echte" Benutzerfragen, einige wurden einfach eingefügt, um dem Benutzer einen Einstieg in WWWOFFLE zu geben und wahrscheinlichen Fragen vorzubeugen.

Sektion 0 - Warum beantwortet diese FAQ meine Frage(n) nicht?

Sektion 1 - Was kann WWWOFFLE (nicht)?
Q 1.1 Beherrscht WWWOFFLE http, https, ftp, finger, gopher, ...?
Q 1.2 Läuft WWWOFFLE auf anderen (nicht-UNIX) Systemen?
Q 1.3 Können die von WWWOFFLE erstellten Seiten angepaßt werden.?

Sektion 2 - WWWOFFLE im Intranet
Q 2.1 Kann WWWOFFLE von anderen Rechnern im Netz benutzt werden?
Q 2.2 Warum können andere Rechner im Netz nicht auf WWWOFFLE zugreifen?
Q 2.3 Warum können andere Rechner im Netz den Verweisen ("links") auf WWWOFFLE's Seiten nicht folgen?
Q 2.4 Gibt es Sicherheitsprobleme im Mehrbenutzerbetrieb?
Q 2.5 Wie kann ich verschiedene Konfigurationen für verschiedene Benutzer einrichten?

Sektion 3 - Hilfe, mein WWWOFFLE funktioniert nicht
Q 3.1 Warum liefert mein Browser eine leere Seite mit WWWOFFLE, funktioniert aber ohne?
Q 3.2 Warum kann WWWOFFLE Adressen nicht finden, die mein Browser findet?
Q 3.3 Warum sagt mein Browser etwas wie "Verbindung von Ihnen geschlossen"?
Q 3.4 Warum führt ein Verweis von einer FTP Adresse zum falschen Rechner?
Q 3.5 Warum behandelt WWWOFFLE Cookies nicht korrekt?
Q 3.6 Warum holt WWWOFFLE alle Seiten neu, die im Offline-Modus betrachtet werden?
Q 3.7 Warum erlaubt WWWOFFLE zu einige kennwortgeschützten Seiten keinen Zugriff?

Sektion 4 - Applets
Q 4.1 Warum startet mein Browser das Applet XYZ nicht?
Q 4.2 Werden unicoded Applets unterstützt?
Q 4.3 Warum zeigt mir Netscape eine 'trustProxy' Fehlermeldung an?

Sektion 5 - Undokumentierte Geheimfunktionen ;-)
Q 5.1 Wie sehe ich, welche abonnierten Seiten letztes Mal geholt wurden?
Q 5.2 Wie kann ich Seiten rekursiv regelmäßig holen (abonnieren)?
Q 5.3 Wie verhindere ich den Zugriff auf den Index?
Q 5.5 Wie kann ich die Performance von WWWOFFLE erhöhen?

Sektion 6 - Mehr Information über WWWOFFLE
Q 6.1 Wer hat WWWOFFLE geschrieben, wann und warum?
Q 6.2 Gibt es WWWOFFLE Mailinglisten?
Q 6.3 Wie/Wem melde ich Programmfehler (Bugs) vom WWWOFFLE?


Sektion 0 - Warum beantwortet diese FAQ meine Frage(n) nicht?

Diese FAQ wird mit jeder neuen Version von WWWOFFLE mitgeliefert. Falls Sie also eine Frage über diese Version von WWWOFFLE haben, kann sie hier noch nicht enthalten sein. Sie wird allerdings ggf. gerne in die Online-Version der FAQ auf http://www.gedanken.demon.co.uk/wwwoffle/version-2.4/ aufgenommen.


Sektion 1 - Was kann WWWOFFLE (nicht)

Q 1.1 Beherrscht WWWOFFLE http, https, ftp, finger, gopher, ...?

Ein paar.

httpJaDie ursprüngliche Version von WWWOFFLE konnte nur http.
ftpJa Seit Version 2.0 gibt es auch Unterstützung für FTP.
fingerJa Seit Version 2.1. Es ist zwar kein Standardprotokoll für Proxies, aber es gibt keinen Grund es nicht einzubauen.
httpsJa! Seit Version 2.4 beherrscht WWWOFFLE transparent verschlüsselte Verbindungen (SSL). Dies beinhaltet auch HTTPS.
gopherNein. Es ist zwar nicht unmöglich, aber ich sehe keinen Grund es zu programmieren, da es offensichtlich von http (bzw. dem WWW) ersetzt wurde.

Q 1.2 Läuft WWWOFFLE auf anderen (nicht-UNIX) Systemen?

Ja, zum Beispiel Win95 / WinNT.

UNIXJa Hier wurde es ursprünglich entwickelt und es sollte eigentlich auf jeder UNIX Variante laufen. Getestet wurde es unter Linux, SunOS 4.1.x, Solaris 2.x, und allen BSD Varianten.
DOS/Windows 3.xNein. Weder die Dateiverwaltung noch die Multiprozessnatur (es sind fast immer mehrere Unterprozesse von wwwoffle gleichzeitig am arbeiten) erlauben eine Version für DOS.
WindowsJa Es gibt jetzt eine 32-bit Windows Version von WWWOFFLE. Dank dafür an das Cygwin Entwicklungskit, welches alle UNIX Systemaufrufe in einer Windows-Umgebung zur Verfügung stellt.
OS/2Vielleicht Es gibt die EMX-Libraries für OS/2, die ähnlich CygWin arbeiten. Damit sollte es kein Problem sein es ebenfalls zu portieren.

Q 1.3 Können die von WWWOFFLE erstellten Seiten angepaßt werden.?

Diese Frage wird häufig gestellt. Manche wollen Javascript, Bilder, und mehr bunte Farben ;-) auf den WWWOFFLE Seiten.

Ab Version 2.2 ist dies kein Problem mehr, da die Seiten, die WWWOFFLE generiert, von HTML Seiten erstellt werden, die jeder an seinen Geschmack anpassen kann. Normalerweise liegen diese Seiten im /var/spool/wwwoffle/html/messages/ Verzeichnis, dort ist auch eine README Datei, die die Struktur erklärt.

Falls Sie WWWOFFLE aus Ihrer Distribution (Redhat, Debian, SuSE, ...) installiert haben, können die Dateien auch in /usr/share/wwwoffle zu finden sein.


Sektion 2 - WWWOFFLE im Intranet

Q 2.1 Kann WWWOFFLE von anderen Rechnern im Netz benutzt werden?

Natürlich, das ist doch eine der Hauptfunktionen von WWWOFFLE. Dies ist seit der ersten Version möglich.

WWWOFFLE kann von sämtlichen Rechnern benutzt werden, die das TCP/IP Protokoll verstehen und in irgendeiner Weise mit dem Rechner vernetzt sind, auf dem WWWOFFLE läuft. Die einzige Bedingung ist, dem jeweiligen Browser zu sagen, daß er WWWOFFLE auch benutzen soll, d.h. WWWOFFLE als Proxy einzustellen.

Q 2.2 Warum können andere Rechner im Netz nicht auf WWWOFFLE zugreifen??

Die Standardeinstellung in der Datei wwwoffle.conf verbietet Zugriff auf den Proxy für alle Rechner außer localhost. Wenn Sie anderen Rechnern Zugriff erlauben wollen, müssen Sie die Datei wie unten beschrieben ändern.

Der AllowedConnect Abschnitt in der Konfigurationsdatei enthält eine Liste von Rechnern, die Zugriff bekommen. Diese Namen werden mit den Namen, mit den sich die Rechner im Netzwerk identifizieren, verglichen und dann wird Zugriff erlaubt oder eben nicht. Es ist möglich, Wildcards zu benutzen, es werden aber keine Hostnamen aufgelöst oder Nameserver befragt.

Zum Beispiel wollen Sie das gesamte Netz 192.168.*.* (Ihr Intranet) auf WWWOFFLE zugreifen lassen. Dann muß die Konfiguration folgendermaßen aussehen:

AllowedConnect
{
 192.168
}

Dies erlaubt allen Rechnern, die dazu passende IPs besitzen, den WWWOFFLE Server zu benutzen.

Q 2.3 Warum können andere Rechner im Netz den Verweisen ("links") auf WWWOFFLE's Seiten nicht folgen?

Einige der Links auf den WWWOFFLE-internen Webseiten zeigen auf andere Seiten innerhalb des Proxys. Hierfür muß dem WWWOFFLE Programm der Name des Rechners bekannt sein, auf dem er läuft, und der auch allen anderen Rechner im Netzwerk bekannt ist. Dies ist der erste Name, der im LocalHost Abschnitt der Konfigurationsdatei auftritt.

Ist Ihr Proxy z.B. allen Rechnern unter dem Namen www-proxy bekannt, müße der Abschnitt so aussehen:

LocalHost
{
 www-proxy
 localhost
 127.0.0.1
}

Der erste wird von WWWOFFLE für Links "auf sich selbst" benutzt, die anderen werden lediglich auf keinen Fall im Cache gehalten.

Q 2.4 Gibt es Sicherheitsprobleme im Mehrbenutzerbetrieb?

Sicherheit ist eine ernste Sache, obwohl sie bei der Entwicklung von WWWOFFLE nicht im Vordergrund stand. Einige Sachen, die es zu beachten gibt, werde ich hier erläutern.

Für die Windows-Versionen ist klar, daß es keine Sicherheitsmechanismen vom System her gibt, wie bei UNIX Systemen. Es ist zum Beispiel unmöglich, Dateien zu erstellen, die von WWWOFFLE aber nicht von anderen Benutzern auf dem System gelesen werden können. Die Sicherheitsfunktionen von WWWOFFLE sind daher nur für UNIX Systeme wirksam.

Kennwort für die Konfigurationsdatei

Die Konfigurationsdatei kann durch ein Kennwort geschützt werden. Dieses wird dann benötigt, um WWWOFFLE online oder offline zu schalten, den Cache zu leeren, zu beenden oder neu zu starten, die Konfiguration zu verändern usw. Da das Kennwort im Klartext in der Konfigurationsdatei angegeben wird, sollte diese Datei auch nur von WWWOFFLE (und ggf. von Administratoren) lesbar sein. Das Kennwort wird von dem wwwoffle Programm nicht verschlüsselt, von dem wwwoffle Server übers Netzwerk nur trivial verschlüsselt.

Proxy-Authentifizierung

Die Möglichkeit, WWWOFFLE mit der "HTTP/1.1 Proxy Authentification" zu benutzen, birgt allerdings dieselben Sicherheitsrisiken wie das Kennwort für die Konfigurationsdatei: Die Kennwörter und die Benutzernamen sind im Klartext in der Konfigurationsdatei enthalten und werden bei der Übertragung übers Netz trivial verschlüsselt. Wie gesagt, Bombensicherheit war nicht der primäre Grund für WWWOFFLE.

WWWOFFLE Server Benutzer/Gruppenkennung (UID/GID)

Die User/Gruppen-IDs, unter denen der WWWOFFLE Server läuft, können in der Konfigurationsdatei (Abschnitt Startup) eingestellt werden. Der Benutzer oder die Gruppe, unter der WWWOFFLE läuft, muß die Konfigurationsdatei lesen können (Schreibzugriffe sind nur nötig, wenn die Datei mit der Interaktiven Konfiguration per Browser verändert werden soll), und müssen in das Cache-Verzeichnis (/var/spool/wwwoffle normalerweise) schreiben und lesen können.
Wenn diese Option benutzt werden soll, dann muß der WWWOFFLE Server von root gestartet werden (sonst kann er seine eigene Benutzer-ID nicht nach dem Start noch ändern).

Löschen von bestellten URLs

Nur derjenige, der die jeweilige URL bestellt hat, kann die Bestellung löschen, und auch nur solange, wie diese Bestellung noch nicht ausgeführt wurde. Dies wird erreicht, indem ein Kennwort über eine Checksumme aus der Bestellung (der entsprechenden Datei aus dem outgoing Verzeichnis) berechnet wird.
Dies ist natürlich nur solange sicher, wie der WWWOFFLE Server der einzige Prozeß ist, der dieses Verzeichnis lesen kann.

Eingebauter Web-Server

Ein sehr simpler Webserver ist in WWWOFFLE eingebaut. Er folgt symbolischen Links, aus Sicherheitsgründen zeigt er aber nur Dateien an, die sowieso jeder lesen kann, und die in einem Verzeichnis liegen, welches von WWWOFFLE gelesen werden kann.
Das heißt allerdings auch, daß von jedem lesbare Dateien, die in einem Verzeichnis stecken, das nur WWWOFFLE lesen kann, nicht sicher sind!

Zugriff auf den Cache

Normalerweise gibt es keine Probleme, Benutzern (Lese-)Rechte auf den Cache zu geben. Eine Ausnahme sind URLs, die ein Kennwort benötigen. Das einzige, was es zu bedenken gibt, ist daß das Aufräumen des Caches ("purge") nicht korrekt funktioniert, wenn jemand z.B. 'grep' auf den gesamten Cache losgelassen hat und in der Konfigurationsdatei der letzte Zugriff auf die jeweiligen Dateien als 'Aufräumzeit'-Basis benutzt wird, da dann alle Dateien als 'neu' erscheinen (weil ja vor kurzem auf sie zugegriffen wurde).

URLs mit Kennwörtern

URLs mit Kennwörtern müssen ebenfalls im Cache gespeichert werden. Um die Sache nicht zu kompliziert zu machen, sind sie in keiner Weise versteckt. Das heißt, jede URL, die eine Benutzerkennung und/oder ein Kennwort benötigt, erscheint in Protokolldateien (logfiles) (nur mit "Debug" oder "ExtraDebug"). Diese Dateien liegen inklusive der Benutzername/Kennwort-Kombination im Cache, deshalb sollte der Cache u.U. mit den Standard-UNIX MItteln für andere Benutzer verborgen werden (Leserechte verweigern).

Zugriff auf den Server

Der Zugriff auf den Proxy ist durch die Liste von Addressen und Rechnernamen im AllowedConnectHosts Abschnitt beschränkt. Standardmäßig steht dieses bloss auf localhost. Zugriffe von anderen Rechnern werden vom Proxy nicht ausgewertet, müssen aber angenommen und verarbeitet werden (damit der Proxy diese Entscheidung treffen kann). Dies kann unter gewissen Umständen einen DoS (Denial of Service) ermöglichen, wo nicht autorisierte Rechner den WWWOFFLE Proxy mit verboteten Anfragen so beschäftigen, daß er auf legitime Anfragen nicht mehr reagieren kann.

Um dies zu umgehen, benutzen Sie am besten die Paketfilter-/Firewallfähigkeit Ihres Betriebssytems (unter Windows ist diese Funktionalität allerdings nicht vorhanden), um nicht autorisierte Zugriffe zu verhindern. Bei Linux geht das folgendermaßen:

  # Kernel 2.2.x: Proxy-Zugriffe nur von localhost erlauben
  /sbin/ipchains -A input -i lo --dport 8080:8081 -p tcp -j ACCEPT
  /sbin/ipchains -A input       --dport 8080:8081 -p tcp -j DENY -l

  # Kernel 2.4.x: Proxy-Zugriffe nur von localhost erlauben
  /sbin/iptables -A INPUT -i lo --dport 8080:8081 -p tcp -j ACCEPT
  /sbin/iptables -A INPUT       --dport 8080:8081 -p tcp -j REJECT

  # Kernel 2.4.x: Proxy-Zugriffe nur von best. Addressen erlauben
  # (geht ähnlich auch mit 2.2.x)
  for ADR in 192.168.1.1 192.168.1.4 192.168.1.24; do
    /sbin/iptables -A INPUT -i eth0 -s $ADR --dport 8080:8081 -p tcp -j ACCEPT
  done
  /sbin/iptables -A INPUT -i eth0 --dport 8080:8081 -p tcp -j REJECT
Um differenziertere Firewall-Regeln aufzustellen, sollten Sie die Manual-Pages für iptables oder ipchains lesen.

Q 2.5 Wie kann ich verschiedene Konfigurationen für verschiedene Benutzer einrichten?

Falls es zwei Gruppen von Benutzern gibt, die den WWWOFFLE Proxy mit verschiedenen Konfigurationen benutzen wollen, gibt es die Möglichkeit, mehrere WWWOFFLE Instanzen laufen zu lassen.

Beispielsweise möchten in einer Schule die Lehrer neue Seiten abfragen können dürfen, aber die Schüler sollen nur im Cache surfen können. Dann ist etwa folgende Konfiguration nötig:
wwwoffle.student.confwwwoffle.teacher.conf
StartUp 
{
   http-port    = 8080
   wwwoffle-port= 8081
   password     = secret
}

OfflineOptions 
{
   <*://*/*> dont-request = yes
}

AllowedConnectUsers
{


}

AllowedConnectHosts
{


}
StartUp 
{
   http-port    = 9080
   wwwoffle-port= 9081
   password     = teacher
}

OfflineOptions 
{

}

AllowedConnectUsers
{
teacher1:password1
teacher2:password2
}

AllowedConnectHosts
{
teacher1pc
teacher2pc
}

Die beiden WWWOFFLE-Instanzen müssen verschiedene Ports benutzen. Sie benutzen dieselben Verzeichnisse für den Cache und somit sind dieselben Webseite für beide Gruppen erreichbar. Für die Schüler sollte ein Kennwort auf den WWWOFFLE-Proxy gesetzt werden, damit sie ihre eigene Konfiguration nicht ändern können, für die Lehrer ist das nicht notwendig. Für die Lehrer ist es sinnvoll, entweder AllowedConnectUsers oder AllowedConnectHosts zur Zugangsbeschränkung zu benutzen.

In dem obigen Beispiel können dann die Schüler im Offline-Modus keine Seiten bestellen und der Online-Modus ist wegen der Kennwortsicherung nicht aktivierbar. Sie starten die beiden WWWOFFLE-Instanzen dann mit der passenden Konfigurationsdatei als Parameter.


Sektion 3 - Hilfe, mein WWWOFFLE funktioniert nicht

Q 3.1 Warum liefert mein Browser eine leere Seite mit WWWOFFLE, funktioniert aber ohne?

Problem: Ohne WWWOFFLE funktioniert alles. Mit WWWOFFLE liefert Ihr Browser nur leere Seiten.

Mögliche Lösungen: (Alle wurden mir von anderen Benutzern mitgeteilt, oder selbst getestet):

Q 3.2 Warum kann WWWOFFLE Adressen nicht finden, die mein Browser findet?

Die häufigste Ursache ist, daß der DNS-Server seit dem Start von WWWOFFLE ungültig geworden ist. Das kann passieren, wenn die Datei /etc/resolv.conf geändert wurde (und quasi jedes Programm zum Herstellen von Internetverbindungen tut dies). Die Lösung ist, daß Sie den WWWOFFLE Proxy nach dem Verbindungsvorgang (und nach dem Auflegen) einmal neu starten, dies läßt sich gängigerweise über Skripte in den /etc/ppp/ip-{up,down}.d/ Verzeichnissen realisieren.

WWWOFFLE benutzt die UNIX-Systemfunktion gethostbyname(), um Rechnernamen auflösen zu können. Diese Funktion liefert nur ein Ergebnis, wenn der zurückgelieferte Name 'authorative' ist, d.h. das Ergebnis "sicher" ist -- sonst gibts eine Fehlermeldung..

"Große" Browser wie Netscape benutzen auch 'unsichere' (non-authorative) Informationen, wenn sie verfügbar sind. Das heißt, daß Netscape auf Adressen zugreifen kann, die für WWWOFFLE nicht erreichbar sind. Die Funktionen, die Netscape dafür benutzt, sind weder eindeutig noch 'sauber' und benötigen relativ viel Arbeit auf einer tiefen Ebene direkt in der Bibliothek, die für das Namensauflösen verantwortlich ist (libresolv). Ich möchte diese Funktionen nicht benutzen, weil sie die Kompatibilität zu vielen UNIX-Derivaten brechen würde und mir kein Standard garantiert, daß diese Funktionalität dort erhalten bleibt.

Dieses Problem tritt allerdings nur auf, wenn Ihr Nameserver eine sehr schlechte Verbindung hat oder Sie ein Konfigurationsproblem haben. Falls ersteres, sollten Sie sich einen anderen Nameserver suchen, oder natürlich bei Ihrem Internet Service Provider (ISP) einmal anklopfen.

Die Lösung

ist, einen lokalen DNS-Server zu benutzen. Das Paket bind, der Standard DNS-Server im Internet, ist allerdings etwas übertrieben für einen einzelnen Rechner (und man öffnet bei falscher Konfiguration leicht eine ganze Reihe Sicherheitslöcher). Eine Alternative ist pnsd, dieser Server cached Anfragen lediglich und benötigt keine/kaum lokale Konfiguration.

Q 3.3 Warum sagt mein Browser etwas wie "Verbindung von Ihnen geschlossen"?

Dies passiert, wenn Sie einige Seiten mit Netscape aufrufen. Der Grund wurde bisher noch nicht eindeutig identifiziert, allerdings tritt es nur in Verbindung mit Netscape und WWWOFFLE auf.

[Ich glaube, es ist eine 'Misfunktion' von Netscape, und ab Version 2.2c von WWWOFFLE ist das Problem behoben. Falls es wieder auftritt, würde ich mich um detaillierte Protokolldateien freuen.]

Q 3.4 Warum führt ein Verweis von einer FTP Adresse zum falschen Rechner?

Sie sind auf einem FTP Server ftp://server.name.com/ und klicken auf einen Link, der nach /dir verweist. Gesunder Menschenverstand erwartet hier, daß Sie nach ftp://server.name.com/dir/ gelangen -- aber manchmal werden Sie nach ftp://dir/ geleitet.

Ich behaupte, das ist eine Fehlfunktion vom Browser und nicht von WWWOFFLE. Es ist irgendwie logisch, daß man auf dem gleichen Server bleibt, wenn kein ftp:// oder http:// am Anfang einer Adresse steht. Warum einige Browser das anders handhaben, verstehe ich nicht.

[Eigentlich sollte dies ab v2.1 von WWWOFFLE nicht mehr auftreten, ist also obsolet.]

Q 3.5 Warum behandelt WWWOFFLE Cookies nicht korrekt?

Cookies sind eine Methode für Webseitenbetreiber, einen Zustand (z.B. "angemeldet") bei Ihnen zu speichern, um sie später wiederzuerkennen. Aus diesem Grunde werden Webseiten, die mit Cookies angefordert werden, niemals aktuell (beispielsweise wenn Cookies zum Zählen der bisherigen Besuche benutzt werden) und schon gar nicht für einen anderen Benutzer gültig.

WWWOFFLE speichert solche Seiten trotzdem zwischen, da es die Netzwerklast reduzieren soll. Man sollte trotzdem Seiten, die mit Cookies arbeiten, niemals als gültig betrachten -- die beste Möglichkeit ist, sie im DontCache Abschnitt in der Konfigurationsdatei einzutragen.

Q 3.6 Warum holt WWWOFFLE alle Seiten neu, die im Offline-Modus betrachtet werden?

Im Offline-Modus kann es passieren, daß eine Seite neu angefordert wird, obwohl sie bereits in einer von WWWOFFLE zwischengespeicherten Version vorliegt. Das kann mehrere Gründe haben. Meistens ist es jedoch der Browser, der WWWOFFLE sagt, daß eine neue Version der Seite erforderlich ist (dieses Verhalten kann man bei den meisten Browsern erzwingen, indem man Shift drückt, während man auf den Reload-Knopf klickt.)

Um dies abzuschalten, gibt es in WWWOFFLE eine Option namens pragma-no-cache, die Anfragen nach einer "garantiert aktuellen" Version der Seite ignoriert und falls vorhanden, die zwischengespeicherte Version liefert.

Q 3.7 Warum erlaubt WWWOFFLE zu einige kennwortgeschützten Seiten keinen Zugriff?

Wenn ein Browser eine Seite mit Kennwort anfordert, gibt es einen Dialog zwischen Browser und Server. Die erste Anfrage [1] wird grundsätzlich ohne Kennwort versucht (und schlägt in diesem Fall fehl), da es keine Möglichkeit gibt, im voraus herasuzufinden, ob ein Kennwort verlangt wird. Der Server sendet nun [2] eine 401 Unauthorized Antwort mit einem Realm (Bereich), für den das Kennwort gelten soll.

Der Browser empfängt die 401-Antwort und fragt den Benutzer [3] nach einem Namen und einem Kennwort. Damit wird die Seite dann erneut angefordert [4] und der Server liefert sie bei erfolgreicher Anmeldung dann auch zurück [5].

WWWOFFLE macht dies für den Benutzer einfacher, allerdings gibt es einiges zu beachten. Viele Browser springen sofort zu Schritt [4], wenn sie die Anmeldedaten bereits kennen. Das hat allerdings zur Folge, daß die angeforderte Seite im Cache landet, ohne daß WWWOFFLE etwas darüber weiß, daß sie ein Kennwort benötigt. Dies ist nur möglich, wenn der Dialog mindestens bei Schritt 2 beginngt.

Daher startet WWWOFFLE bei Anforderung von kennwortgeschützten Seiten grundsätzlich einen kennwortlosen Versuch, die Seite abzurufen. Damit weiß WWWOFFLE, daß diese Seite auch aus dem Cache nur mit dem Kennwort abzurufen sein soll.

Das Problem ist nun, daß es einige wenige Webseiten gibt, die den Browser bei einem kennwortlosen Versuch zu einer Login-Seite zurückleiten und WWWOFFLE nicht die benötigte 'zweite Chance' geben. Somit funktioniert die Anmeldung mit WWWOFFLE nicht wie gewünscht. Dieses Verhalten läßt sich daher mit der Option try-without-password in der Konfigurationsdatei abschalten.


Sektion 4 - Applets

Q 4.1 Warum startet mein Browser das Applet XYZ nicht?

[Walter Pfannenmueller <pfn@online.de> schreibt:]
Ich nehme an, Sie haben Java-Unterstützung aktiviert. Ihr Browser erzählt etwas von "Kann Applet xyz.class nicht starten" Gucken Sie nach, ob die Datei von WWWOFFLE heruntergeladen wurde. Wenn die Datei da ist, öffnen Sie eine Java Konsole (dies sollte Ihr Browser können) und holen Sich Details.

Möglicherweise ist es eine Sicherheitsverletzung. Jeder Browser hat seine eigenen Vorstellungen von Sicherheit, die von der SecurityManager Klasse ausgeführt werden. Gucken Sie ins Handbuch oder in die Hilfe, wie Sie diese anpassen können.

Falls Ihr Applet natürlich versucht, auf irgendwelche Server-funktionen zuzugreifen (Servlets, RMI, CORBA), sind wir am Ende der Fahnenstange eines Offline-Readers.

Q 4.2 Werden unicoded Applets unterstützt?

[Walter Pfannenmueller <pfn@online.de> schreibt:]
Ich weiß es nicht. Ich wandle diese Namen nach UTF8 um und der Rest hängt von Ihrem Dateisystem - oder das ihres Hosts - ab. Java Compiler haben auch Probleme mit Unicode, obwohl es unterstützt sein sollte. Ich wüßte gerne, wie man Unicode nach UTF8 umwandelt - die Implementation in javaclass.c sieht ziemlich schräg aus.

Q 4.3 Warum zeigt mir Netscape eine 'trustProxy' Fehlermeldung an?

[Walter Pfannenmueller <pfn@online.de> schreibt:]
Die Meldung sollte etwa lauten wie

Could not resolge IP for host ...... See the trustProxy property.

Netscape versucht, die Quelladdresse des Applets herauszubekommen. Im Offline-Modus ist das nicht möglich, daher müssen wir dem Browser sagen, daß er dem WWWOFFLE Proxy auch 'trauen' kann. Dies ist mit einer Zeile in der preferences.js (UNIX) oder prefs.js (Windows) möglich:

  user_pref(security.lower_java_network_security_by_trusting_proxies", true);

Vorher (!) sollte man alle Browserfenster schließen, da diese Datei beim Beenden von Netscape überschrieben wird. Dies sollte für alle 4.x Netscape Browser funktionieren.

Mehr Informationen gibt es hier: http://developer.netscape.com/docs/technote/security/sectn3.html


Sektion 5 - Undokumentierte Geheimfunktionen ;-)

Q 5.1 Wie sehe ich, welche abonnierten Seiten letztes Mal geholt wurden?

Am einfachsten: http://localhost:8080/index/monitor/?atime. Auf jede Seite wird beim Erstellen einmal zugegriffen, so daß die neuesten Seiten hier stets ganz oben stehen.

Q 5.2 Wie kann ich Seiten rekursiv regelmäßig holen (abonnieren)?

Dies geht am besten mit einer Kombination von rekursiver Bestellung und Abonnement. Bestellen Sie die Seite ganz normal (http://localhost:8080/refresh-options/), auf der Bestätigungsseite gibt es unten die ganz normale WWWOFFLE Leiste, die an jeder Seite hängt. Dort können Sie jetzt auf "Abonnieren" klicken und die rekursive Bestellung regelmäßig ausführen lassen (http://localhost:8080/monitor-options/).

Q 5.3 Wie verhindere ich den Zugriff auf den Index?

Zugriff auf den Index kann verhindert werden, indem einfach WWWOFFLE angewiesen wird, diese Seiten nicht mehr zu liefern

DontGet
{
 http://localhost:8080/index
}
Stellen Sie sicher, daß der Name, den Sie hier angeben, der erste in der LocalHost Sektion ist, denn dieser wird verglichen.

Q 5.5 Wie kann ich die Performance von WWWOFFLE erhöhen?

Das kommt drauf an, was genau Sie erhöhen möchten.

Wenn WWWOFFLE die zwischengespeicherten Seiten schneller liefern soll

WWWOFFLE speichert Webseiten auf der Festplatte zwischen. Die Festplatte kann sehr leicht zum Flaschenhals werden. Versuchen Sie es mit einer eigenen Partition oder sogar Cache-Festplatte, einer schnelleren Festplatte, einem eigenen IDE-Controller oder gar SCSI.

Prüfen Sie, ob die Treiber Ihres Betriebssystems genügend optimiert arbeiten. Benutzen Sie (falls IDE) auf jeden Fall UDMA-Transfers, diese können mit dem Programm hdparm eingestellt werden.

Wählen Sie das richtige Dateisystem. Falls Sie Linux benutzen, können Sie statt ext2 ReiserFS benutzen, welches bei vielen kleinen Dateien effizienter und schneller ist (aber auch mehr CPU-Leistung benötigt). Verschiedene mount-Optionen erhöhen ebenfalls die Performance (z.B. 'noatime'). Sie können ebenfalls die buffer-cache Optionen bei Linux vergrößern:

echo 25 30 75 > /proc/sys/vm/buffermem
echo 10 10 65 > /proc/sys/vm/pagecache

Sie können die Konfigurationsdatei ebenfalls optimieren. Benutzen Sie für URLs wo es geht Wildcards statt einzelne Einträge. Benutzen Sie wenige Einträge in de DontGet usw. Abschnitten, das reduziert die Zeit, die WWWOFFLE benötigt, um die richtige URL zu finden. Schalten Sie die Änderung von HTML- und GIF-Dateien ab (der ModifyHTML Abschnitt). Verkleinern Sie das Maximalalter im Purge Abschnitt (gibt einen kleineren Cache).

Wenn WWWOFFLE weniger Netzwerklast erzeugen soll

Lassen Sie WWWOFFLE koprimierte Seiten anfordern und weiterleiten (request-compressed, reply-compressed), für Server, die dies unterstützen. Komprimiertes HTML spart bis zu 80% Bandbreite (und damit Download-Zeit), kostet aber mehr CPU-Leistung auf dem Proxy-Server.

Speichern Sie statische Seiten (Bilder, z.B. Logos usw.) für lange Zeit, diese ändern sich selten. Falls Sie eine Wählverbindung habenn oder WWWOFFLE aus anderen Gründen öfters zwischen Offline- und Online-Modus schalten lassen, lassen Sie WWWOFFLE grundsätzlich Webseiten nur einmal pro Online-Sitzung herunterladen (request-changed-once). Beispielsweise

	OnlineOptions
	{
	    <http://images*.slashdot.org> request-changed = 4w
	    <http://*slashdot.org> request-changed-once = yes
	}

	Purge
	{
	    <http://images*.slashdot.org> age = 6w
	    <http://*slashdot.org> age = 4w
	}

Mehr Seiten können im Cache gehalten werden, wenn Sie die age Option im Purge-Abschnitt anpassen, für alle Seiten oder selektiv für einige. Der DontGet Abschnitt bietet auch einige Möglichkeiten. Seien Sie aber fair und blockieren Sie nicht die oft einzige Finanzierungsgrundlage von Seiten, die Sie gut finden und daher regelmäßig nutzen: Das wäre einerseits unfair und zum anderen gibt es Bandbreite, Server usw. auch nicht umsonst [Anm.d.Übers.].

Verhindern Sie bei Seiten, die dies nicht erfordern (ein Forum wäre z.B. ungeeignet) das erzwungene erneute Laden (request-changed-once, request-expired, request-no-cache).


Sektion 6 - Sektion 6 - Mehr Information über WWWOFFLE

Q 6.1 Wer hat WWWOFFLE geschrieben, wann und warum?

WWWOFFLE wurde von Andrew M. Bishop (amb@gedanken.demon.co.uk) geschrieben, von 1996-2001.

Es gibt eine WWWOFFLE Homepage im Web: http://www.gedanken.demon.co.uk/. Diese wird Sie mit Neuigkeiten, Anleitungen und neuen Versionen versorgen können.

Eine Ur-Version des Programms wurde in Perl geschrieben, aber die Funktionalität und Geschwindigkeit ließ zu wünschen übrig und so wurde das Projekt WWWOFFLE in den Weihnachtsferien 1996 ins Leben gerufen -- ursprünglich als eine kleine Sammlung C Code, um die Perl-Version zu verbessern.

Nach der Betaversion 0.9 im Januar 1997 war das Interesse schon sehr groß, so daß die Version 1.0 auch noch im Januar 1997 herauskam. Im Dezember 1997 erschien die Version 2.0, nach einigen Zwischenversionen. Diese enthielt unter anderem FTP Unterstützung und eine komplette Reorganisation des Codes, eine Änderung des Cache-Formates, damit künftige Versionen leichter zu überblicken waren.
Version 2.1 kam im März 1998 mit weiteren neuen Funktionen, 2.2 im Juni 1998 und 2.3 im August 1998.

Die Win32-Version des Programmes wurde möglich durch Version beta-20 des Cygwin Entwicklungskits, seit Oktober 1998, als Version 2.3e herauskam.

Das WWWOFFLE Programm kann frei verteilt werden, es gilt die GNU Public Licence (siehe die Datei 'COPYING').

Q 6.2 Gibt es WWWOFFLE Mailinglisten?

Es gibt mittlerweile vier Mailinglisten für WWWOFFLE. Sie können auf zwei Arten abonniert werden - auf der WWWOFFLE Homepage (siehe oben) und per eMail.

wwwoffle-announceAnkündigungen von neuen Versionen..
wwwoffle-beta-announceAnkündigungen von Entwicklerversionen. Nur nützlich für jemanden, der aktiv an der Entwicklung teilhaben will und auch Zeit fürs Testen aufbringen kann.
wwwoffle-usersFür allgemeine Benutzerdiskussionen, abgesehen von betriebssystemspezifischem.
wwwoffle-win32Für allgemeine Diskussionen über die Win32 Version.

Die ersten beiden sind lediglich für Ankündigungen vom Autor, es finden keine Diskussionen statt. Die letzten beiden sind für Benutzer, hier darf auch geschrieben werden.

Um eine dieser Listen zu abonnieren, schicken Sie eine eMail an majordomo@gedanken.demon.co.uk mit dem Inhalt subscribe "<gruppenname>" (z.B. "subscribe wwwoffle-announce").

Q 6.3 Wie/Wem melde ich Programmfehler (Bugs) vom WWWOFFLE?

Via eMail können Sie sie an meine Adresse schicken (siehe oben), bitte erwähnen Sie WWWOFFLE im Betreff. Ansonsten gibt es auf der Homepage von WWWOFFLE (siehe oben) auch eine Kommentar/Feedback-Ecke.

Allerdings sollten Sie, bevor Sie einen vermeintlichen 'Bug' melden, sowohl die FAQ, als auch die Homepage gelesen haben: Vielleicht ist der "Fehler" schon Monate zuvor als Bedienungsfehler oder ähnliches entlarvt worden.

Können Sie den Fehler reproduzieren, starten Sie WWWOFFLE bitte als

    # bash:
    wwwoffled -d5 -c /etc/wwwoffle/wwwoffle.conf > /root/wwwoffle.log 2>&1
    
    # csh/tcsh:
    wwwoffled -d5 -c /etc/wwwoffle/wwwoffle.conf >& /root/wwwoffle.log

dann produzieren Sie den Fehler, und schicken mir die Fehlermeldungen.