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?
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.
Ein paar.
http | Ja | Die ursprüngliche Version von WWWOFFLE konnte nur http. |
ftp | Ja | Seit Version 2.0 gibt es auch Unterstützung für FTP. |
finger | Ja | Seit Version 2.1. Es ist zwar kein Standardprotokoll für Proxies, aber es gibt keinen Grund es nicht einzubauen. |
https | Ja! | Seit Version 2.4 beherrscht WWWOFFLE transparent verschlüsselte Verbindungen (SSL). Dies beinhaltet auch HTTPS. |
gopher | Nein. | Es ist zwar nicht unmöglich, aber ich sehe keinen Grund es zu programmieren, da es offensichtlich von http (bzw. dem WWW) ersetzt wurde. |
Ja, zum Beispiel Win95 / WinNT.
UNIX | Ja | 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.x | Nein. | Weder die Dateiverwaltung noch die Multiprozessnatur (es sind fast immer mehrere Unterprozesse von wwwoffle gleichzeitig am arbeiten) erlauben eine Version für DOS. |
Windows | Ja | 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/2 | Vielleicht | Es gibt die EMX-Libraries für OS/2, die ähnlich CygWin arbeiten. Damit sollte es kein Problem sein es ebenfalls zu portieren. |
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.
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.
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.
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.
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.
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.
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.
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).
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.
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!
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 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).
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 REJECTUm differenziertere Firewall-Regeln aufzustellen, sollten Sie die Manual-Pages für
iptables
oder ipchains
lesen.
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.conf | wwwoffle.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.
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):
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.
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.
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.]
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.]
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.
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.
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.
[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.
[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.
[Walter Pfannenmueller <pfn@online.de> schreibt:]
Die Meldung sollte etwa lauten wie
Could not resolge IP for host ...... See the trustProxy property.
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
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.
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/).
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.
Das kommt drauf an, was genau Sie erhöhen möchten.
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).
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.
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
).
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').
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-announce | Ankündigungen von neuen Versionen.. |
wwwoffle-beta-announce | Ankü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-users | Für allgemeine Benutzerdiskussionen, abgesehen von betriebssystemspezifischem. |
wwwoffle-win32 | Fü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").
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.