Sezione 0 - Perché non c'è una risposta alla mia domanda in questa FAQ?
Sezione 1 - Cosa fa WWWOFFLE (e cosa non fa)
D 1.1 WWWOFFLE supporta http, ftp, finger, https, gopher, ...?
D 1.2 WWWOFFLE funziona su altri sistemi diversi da UNIX?
D 1.3 Si può modificare WWWOFFLE in modo che nelle pagine che genera ...?
Sezione 2 - Come usare WWWOFFLE per servire un'intranet
D 2.1 Si può accedere al proxy WWWOFFLE da client diversi da localhost?
D 2.2 Perché i client remoti non possono accedere al proxy WWWOFFLE?
D 2.3 Perché i client remoti non riescono a seguire tutti i collegamenti?
D 2.4 Quali sono le caratteristiche di sicurezza di WWWOFFLE in un ambiente multi-utente?
D 2.5 Come posso avere diverse configurazioni per differenti gruppi o utenti?
Sezione 3 - Cosa cercare quando WWWOFFLE non sembra funzionare
D 3.1 Perché il mio browser mi da una pagina vuota con WWWOFFLE, ma non senza di esso?
D 3.2 Perché WWWOFFLE non riesce a trovare un host quando senza di esso il browser lo trova?
D 3.3 Perché il mio browser dice "Connection reset by peer" mentre navigo?
D 3.4 Perché se seguo un collegamento su un sito FTP mi porta su un server sbagliato?
D 3.5 Perché WWWOFFLE non gestisce correttamente i Cookie?
D 4.1 Perché il mio Browser non avvia l'applet XYZ?
D 4.2 Sono supportati i nomi delle applet in formato unicode?
D 4.3 Perché il mio Browser Netscape solleva l'eccezione di sicurezza trustProxy?
Sezione 5 - Come usare le altre funzioni avanzate di WWWOFFLE
D 5.1 Come posso verificare quali pagine controllate sono state scaricate l'ultima volta online?
D 5.2 Come faccio uno scaricamento ricorsivo a intervalli regolari?
D 5.3 Come impedire agli utenti di accedere all'indice?
D 5.4 Come posso usare JunkBuster con WWWOFFLE?
Sezione 6 - Altre informazioni su WWWOFFLE
D 6.1 Chi ha scritto WWWOFFLE, quando e perché?
D 6.2 Quali mailing list su WWWOFFLE sono disponibili?
D 6.3 Come segnalo un bug in WWWOFFLE?
Alcuni di questi sono supportati e altri no. http : Sì La versione originale di WWWOFFLE supporta solo http. ftp : Sì Dalla versione 2.0 c'è il supporto per le URL ftp. finger : Sì Dalla versione 2.1 c'è il supporto per finger. Sebbene questo non sia un protocollo standard per i proxy, non c'è una ragione per cui esso non possa essere utilmente eseguito. https : Sì Dalla versione 2.4 c'è il supporto per il proxy trasparente delle connessioni Secure Socket Layer (SSL). Questo include il protocollo https. gopher : No Questo è un protocollo che è molto meno popolare da quando il WWW è realmente decollato. Guardando i browser che lo supportano, non sembrerebbe impossibile, ma il suo mercato sembra essere limitato.
Per esempio DOS / Win3 / Win95 / WinNT / OS/2. UNIX = Sì Questo è il sistema per il quale il programma è stato inizialmente progettato e scritto, dovrebbe funzionare su molte versioni di UNIX. So che funziona su Linux, SunOS 4.1.x, Solaris 2.x, *BSD. DOS/Win3 = No Il programma non è progettato per il DOS, i nomi dei file usati e la natura multi-processo per programma non lo permettono. Win95/Win98/WinNT = Sì (Parzialmente) Un versione Windows 32-bit del programma è ora disponibile grazie al kit di sviluppo Cygwin che fornisce una libreria di chiamate di sistema UNIX disponibile per MS Windows. OS/2 = Forse Io non conosco un equivalente del prodotto Cygwin per OS/2, se esiste allora è possibile portarlo su OS/2 come per Windows 95 / Windows NT più sopra.
Questa è una domanda posta molto di frequente. Le persone vorrebbero vedere Javascript, immagini, colori diversi ... sulle pagine generate da WWWOFFLE. Dalla versione 2.2 questo non è più un problema, dal momento che è possibile personalizzare tutte le pagine web generate da WWWOFFLE stesso. Questo significa che il colore di sfondo e la dimensione dei caratteri possono essere cambiati per soddisfare le tue preferenze. Per trovare come fare questo, guarda nella directory /var/spool/wwwoffle/html/messages e leggi il file README.
Sì, si può, questa agevolazione è presente dall'inizio. Gli altri client possono essere qualsiasi tipo di computer che è connesso al server su cui sta girando il programma wwwoffle. L'unico requisito è che siano connessi via rete al server e che i browser su di essi siano configurati per accedere al proxy WWWOFFLE.
L'impostazione predefinita nel file wwwoffle.conf è di non consentire l'accesso al proxy a client diversi da localhost. Per permettere loro di accedere al proxy il file wwwoffle.conf deve essere modificato come descritto in seguito e la nuova configurazione ricaricata. La sezione AllowedConnect del file di configurazione contiene una lista degli host cui è permesso connettersi al proxy WWWOFFLE. Questi nomi sono confrontati con il nome che WWWOFFLE ottiene quando si stabilisce una connessione e l'accesso è concesso o negato. Una specie di confronto con caratteri jolly è applicato alle voci in questa lista, ma non è eseguita nessuna altra verifica extra su questi nomi. Per esempio se stai usando la classe di indirizzi IP privati 192.168.*.* per la tua intranet allora la tua sezione AllowedConnect nel file di configurazione dovrebbe essere simile alla seguente. AllowedConnect { 192.168.* } Questo permetterà a tutti gli host che rientrano in questo insieme di indirizzi IP di accedere al proxy WWWOFFLE.
Alcuni dei collegamenti che sono generati nelle pagine web che provengono dal proxy WWWOFFLE necessitano di puntare ad altre pagine nel proxy. Per poter fare questo il nome dell'host su cui sta girando il proxy deve essere specificato nella sezione LocalHost del file di configurazione. Per esempio se il computer su cui gira il proxy WWWOFFLE si chiamasse www-proxy, allora la sezione LocalHost del file di configurazione sarebbe simile alla seguente. LocalHost { www-proxy localhost 127.0.0.1 } Il primo dei nomi è quello usato da WWWOFFLE per generare questi collegamenti, Gli altri sono usati per i server che non sono inseriti in cache dal proxy.
La sicurezza è una caratteristica che avevo considerato come un estensione quando ho scritto WWWOFFLE, sebbene non sia stata una delle mie preoccupazioni più grandi. Le caratteristiche sono elencate di seguito. Per la versione Win32 si dovrebbe rilevare come in Win95/98 non ci sia la sicurezza a livello di utente fornita da UNIX. Non è possibile quindi creare file leggibili da WWWOFFLE e non da altri utenti. Le caratteristiche di sicurezza che sono presenti in WWWOFFLE non sono quindi applicabili a questi sistemi. Password del file di configurazione Questo file ha una password specificata al suo interno nella Sezione StartUp che è usata per limitare l'accesso alle impostazioni di WWWOFFLE. Se impostata, questa password deve essere usata per mettere WWWOFFLE online, svuotare la cache, fermare il server, modificare il file di configurazione ecc. Se hai impostato una password allora dovresti rendere il file leggibile solo da utenti autorizzati. La password è inviata come testo in chiaro quando si usa il programma wwwoffle per controllare il server wwwoffled. La codifica usata per l'autenticazione delle pagine web è banale. Autenticazione Proxy Con la possibilità di poter controllare l'accesso a WWWOFFLE usando il metodo di Autenticazione Proxy HTTP/1.1, ci sono i pericoli aggiuntivi per la sicurezza legati ad esso. Fondamentalmente si tratta dello stesso usato per la password del file di configurazione, i nomi degli utenti e le password sono testo in chiaro nel file di configurazione e la password è inviata al server usando lo stesso metodo banale di codifica. Uid/gid del server WWWOFFLE L'uid e gid del processo del server wwwoffled possono essere controllati con le opzioni run-uid e run-gid nella sezione StartUp del file di configurazione. Questo uid/gid deve poter leggere il file di configurazione (la scrittura non è richiesta a meno che si usi la pagina interattiva di modifica) e avere accesso in lettura/scrittura alla directory dello spool. Se si usa questa opsione allora il server deve essere avviato da root. Eliminazione delle URL richieste Solo l'utente che ha richiesto una pagina può eliminare quella richiesta, e quindi solo quando la richiesta di eliminazione è fatta immediatamente. Questo perché viene generata una password tramite hashing tra il contenuto del file nella directory di uscita. Questo significa che l'accesso in lettura per questa directory deve essere negato affinché questa sia sicura. Il server web integrato Questo è un server molto semplice, seguirà i collegamenti simbolici, e come misura di sicurezza solo i file leggibili da tutti sono accessibili. Essi devono inoltre essere in una directory che sia leggibile dal server wwwoffled. Non è fatto alcun controllo su ogni componente della directory, così non sono sicuri file leggibili da tutti in una directory leggibile solo dal uid che lancia wwwoffled. Accesso alla cache Non ci sono in genere problemi nel permettere agli utenti di accedere in sola lettura alla cache fornita (ma guarda le URL con password più in basso). L'unica preoccupazione è che se si svuota la cache in base alla data di accesso dei file, questa potrebbe essere rovinata dall'avvio di grep nella cache. URL con Password Le URL che usano nomi utente e password devono essere memorizzate nella cache. Per semplicità esse non sono nascoste in alcun modo. Questo siglnifica che qualsiasi URL che usa nome utente/password in essa può essere svelata dai file di log (solo nei livelli Debug o ExtraDebug). Anche i file nella cache contengono informazioni su nome utente/password e dovrebbero essere resi inaccessibili agli utenti per questo motivo.
Quando ci sono due gruppi di utenti che accedono alla stessa cache di WWWOFFLE ma dove ogni gruppo ha diverse configurazioni di WWWOFFLE, è possibile lanciare due istanze di WWWOFFLE. Per esempio in una scuola può essere richiesto che gli studenti abbiano accesso alla cache ma non possano richiedere nuove pagine. Gli insegnanti devono accedere alla stessa cache ed essere capaci di usare WWWOFFLE online e richiedere pagine quando sono offline. I due file di configurazione di WWWOFFLE saranno simili in molti aspetti, ma ci saranno le differenze elencate di seguito. -- wwwoffle.studenti.conf -- -- wwwoffle.insegnanti.conf -- StartUp | StartUp { | { http-port = 8080 | http-port = 9080 wwwoffle-port = 8081 | wwwoffle-port = 9081 password = secret | password = teacher } | } | DontRequestOffline | DontRequestOffline { | { *://*/* | } | } | AllowedConnectUsers | AllowedConnectUsers { | { | teacher1:password1 | teacher2:password2 } | } | AllowedConnectHosts | AllowedConnectHosts { | { | teacher1pc | teacher2pc } | } Le due copie di WWWOFFLE devono usare diversi numeri di porte. Usano la stessa directory di spool e quindi le stesse pagine web sono disponibili per entrambi gli insiemi di utenti. Dovrai avere una password sulla versione per gli studenti di WWWOFFLE per impedire le modifiche del file di configurazione, ma per gli insegnanti non dovrebbe essere necessaria. Per evitare che gli studenti possano accedere alla versione di WWWOFFLE degli insegnanti non devi usare nè la sezione AllowedConnectHosts nè quella AllowedConnectUsers del file di configurazione. Queste restringeranno l'accesso all'insieme di macchine da cui accedono gli insegnanti o richiederanno che nome utente/passwrd siano inseriti prima che la navigazione inizi. Nell'esempio precedente non è permesso agli studenti di richiedere qualsiasi pagina quando offline. Questa versione di WWWOFFLE non è mai usata in modalità online, cosicché non c'è la possibilità per gli studenti di navigare online. Solo la versione di WWWOFFLE degli insegnanti è usata in modalità online.
Può capitare che quando si visita una pagina web usando un browser e si usa WWWOFFLE come proxy non si riceva nulla mentre quando si accede al sito direttamente senza WWWOFFLE la pagina sia visibile. Questo può accadere per una serie di cause (tutte riportatemi o testate da me): a) Il server web cui stai accedendo richiede l'header User-Agent. Se non è presente o impostata su un valore non comune (non per Netscape o IE), allora esso rimanda una pagina vuota. In questo caso se hai impostato la sezione CensorHeader del file di configurazione per rimuovere l'header User-Agent, allora dovresti o non censurare questa riga header o impostare una stringa di sostituzione che sia accettabile. b) Come sopra, ma non importa quale sia il valore dell'header per ricevere una pagina non vuota. La soluzione è la stessa salvo che può essere usata qualsiasi stringa User-Agent. c) Il server web usa i cookie per mantenere lo stato. Questo è abbastanza comune nei siti che sono più attenti alla forma che ai contenuti, spesso senza avvertire. d) Il browser e il server stanno provando ad usare estensioni HTTP/1.1 che WWWOFFLE sta ignorando.
Il motivo più probabile è che il server DNS che era stato configurato quando WWWOFFLE era stato avviato non è più valido. Questo succede per esempio se il file /etc/resolv.conf è cambiato dopo l'avvio di wwwoffled. Questo non è un problema solo di WWWOFFLE, ma influirà su alcuni (la maggior parte) dei programmi che erano in funzione prima che la configurazione del DNS cambiasse. Quando WWWOFFLE cerca un nome di un host usa la chiamata di funzione gethostbyname() della libreria standard UNIX (libc). La parte di ricerca dei nomi della libc (chiamata libreria di risoluzione) è inizializzata quando un programma per la prima volta usa una sua funzione. Quando una funzione della libreria di risoluzione è eseguita in seguito, essa userà la configurazione che era nel punto in cui la prima funzione l'aveva usata. La modifica della configurazione del DNS può avvenire senza che tu te ne accorga. Alcuni dei programmi per configurare facilmente il PPP cambiano il file /etc/resolv.conf in base a quale ISP ti stai connettendo. Un esempio di programma che fa questo è kppp. I progetti di grandi browser (Netscape in particulare) possono usare altri metodi per risolvere i nomi diversi da quelli della libreria standard. Questo significa che essi possono funzionare anche se la configurazione del DNS è cambiata da quando è stato avviato. Un Netscape funzionante e un WWWOFFLE non funzionante possono sognificare che la configurazione del tuo DNS è cambiata e non è un bug di WWWOFFLE.
Questo succede usando Netscape per accedere ad alcune pagine web. La causa non è conosciuta, ma il problema si presenta solo quando si usa WWWOFFLE, e non quando si effettua una connessione diretta.
Se c'è una directory chiamata '/dir' su un server ftp e carichi la pagina 'ftp://server/', otterrai una lista della directory che include un collegamento a '/dir'. Seguire questo collegamento dovrebbe portare il browser a 'ftp://server/dir/', ma su alcuni brower porta invece a 'ftp://dir/'. Penso che questo comportamento sia dovuto al browser e non a WWWOFFLE. Se sei andato a 'http://server/' e hai seguito il collegamento a '/dir/', allora dovresti aspettarti di andare a 'http://server/dir/' e non a 'http://dir/'. Questo è il senso comune. Non sono sicuro del perché il browser faccia differenza tra ftp ed http. [Questo dovrebbe essere risolto nella versione 2.1 di WWWOFFLE, così non è veramente appropriato in questa versione della FAQ]
I normali proxy non possono fare il caching dei risultati di URL richieste con Cookie perché i risultati sono diversi per ogni utente. WWWOFFLE eseguirà il caching delle pagine che contengono cookie per ridurre il traffico di rete. Se vuoi usare i cookie quando navighi allora qualsiasi pagina che vedi non dovrebbe essere considerata valida quando la vedi offline. Il modo migliore di gestire ciò, se c'è un sito particolare che visiti, è di inserirlo nella sezione DontCache del file di configurazione. Non è possibile per WWWOFFLE inserire in cache pagine che usano cookie per controllare il contenuto alla stessa maniera di come gestisce le pagine che non usano cookie. Qualsiasi realizzazione di gestione di cookieavrà bisogno di dare risposte diverse agli utenti in base al cookie che è nella richiesta. Questo significherebbe inserire in cache pagine diverse per la stessa URL. Ma c'è il problema che andare alla pagina A potrebbe impostare un cookie e quindi andare alla pagina B darebbe una pagina diversa. Così, per esempio, se hai un cookie e hai la pagina B nella cache quando sei offline, seguire il collegamento da B verso A ti potrebbe dare un nuovo cookie da A (quando andrai online e scaricherai A). Questo significa che non potrai tornare indietro verso B quando sarai offline perché il cookie è diverso (e così la pagina, ma tu non ce l'hai nella cache). Un problema ancora peggiore è che ricaricando la pagina C con lo stesso cookie ti da una pagina diversa ogni volta. Questo perché il cookie è usato per contare il numero di volte che hai visitato la pagina. Non c'è un modo per sapere ciò e quindi otterresti la stessa pagina C (quella nella cache) anche se dovresti riceverne un'altra diversa.
[Walter Pfannenmueller <pfn@online.de> scrive:] Suppongo che tu abbia abilitato il supporto per java. Il tuo browser dice qualcosa come "Can't start Applet XYZ.class". Controlla se il file è stato scaricato con successo da WWWOFFLE. Se il file è accessibile, apri una console java (il tuo browser dovrebbe fornire qualcosa di simile) e ricava altri dettagli sul problema. Probabilmente è una violazione della sicurezza. Ogni browser ha il proprio gestore della sicurezza w dovresti consultare il manuale su come abbassare queste restrizioni. Se la tua applet comunque prova a contattare qualche funzionalità del server (servlets, RMI, CORBA), siamo ai limiti delle possibilità per un lettore offline.
[Walter Pfannenmueller <pfn@online.de> scrive:] Non lo so. Io trasformo quei nomi nella codifica UTF8 e il resto dipende da quello che il tuo filesystem o quello dell'host fa con essa. Anche i compilatori Java hanno problemi con unicode, anche se esso dovrebbe essere supportato. Mi piacerebbe sapere come implementare la trasformazione da Unicode a UTF8. L'implementazione in javaclass.c sembra in qualche modo maldestra.
[Walter Pfannenmueller <pfn@online.de> scrive:] Il messaggio d'errore dovrebbe essere: Could not resolve IP for host ... See the trustProxy property. Il browser Netscape prova a verificare l'indirizzo IP d'origine dell'host. Mentre si è offline questo non è possibile. Quindi devi convincere il browser a fidarsi del proxy. Per fare questo devi trovare il file delle preferenze preferences.js in UNIX o prefs.js in Windows. Modifica il file, anche se dice "don't edit" e inserisci la riga: user_pref("security.lower_java_network_security_by_trusting_proxies", true); da qualche parte. Assicurati di aver chiuso tutte le finestre del browser, perché il file delle preferenze sarà.sovrascritto in chiusura. Questo dovrebbe funzionare per tutti i Netscape 4.0x e 4.5. Per altre informazioni dai uno sguardo a: http://developer.netscape.com/docs/technote/security/sectn3.html
La maniera più semplice per fare ciò è di andare all'indice delle pagine web controllate e ordinarle per "Tempo di Accesso" (http://localhost:8080/index/monitor/?atime). Ogni pagina è visitata quando è controllata, così quelle controllate più di recente sono quelle in cima all'elenco.
Questa è una combinazione delle opzioni di scaricamento ricorsivo e di controllo. Se selezioni la pagina che desideri nell'indice delle pagine da scaricare ricorsivamente (http://localhost:8080/refresh-options/) con le opzioni che vuoi e premi il pulsante, ti sarà presentata una pagina che ti informa che la richiesta è stata memorizzata. C'è un collegamento su di essa che ti permette di controllare questa richiesta, portandoti alla normale pagina di controllo (http://localhost:8080/monitor-options), ma con il campo dell'URL già compilato.
L'accesso agli indici può essere negato agli utenti usando la sezione DontGet del file di configurazione. DontGet { http://localhost:8080/index } Devi assicurarti che il nome dell'host inserito sia il primo che compare nella sezione LocalHost dal momento che è questo che verrà controllato.
L'Internet JunkBuster è un programma che può filtrare molti degli avvertimenti che costituiscono spam e altre coratteristiche delle pagine web. Le più recenti versioni di WWWOFFLE aggiungono molte delle caratteristiche del programma JunkBuster, ma non tutte. Se guardi le opzioni offerte da WWWOFFLE potrai decidere se hai bisogno di usare JunkBuster. Se decidi che vuoi usare entrambi i programmi allora ci sono due possibilità: 1) Browser <-> WWWOFFLE <-> JunkBuster <-> Internet Ogni pagina richiesta dall'utente e bloccata da JunkBuster avrà il messaggio di errore di JunkBuster memorizzato nella cache di WWWOFFLE. Ogni scaricamento ricorsivo o scaricamento di immagini fatto da WWWOFFLE in background passa attraverso JunkBuster e i suoi messaggi d'errore sono inseriti nella cache. 2) Browser <-> JunkBuster <-> WWWOFFLE <-> Internet Qualsiasi pagina richiesta dall'utente e bloccata da JunkBuster non sarà inserita nella cache di WWWOFFLE. Ogni scaricamento ricorsivo o scaricamento di immagini fatto da WWWOFFLE in background non passa attraverso JunkBuster e sarà inserito nella cache di WWWOFFLE, ma bloccato quando il browser tenterà di visualizzarlo. Se decidi che WWWOFFLE farà molti scaricamenti perché lo stai usando per navigare offline allora il primo metodo è il migliore. Se decidi che lo userai solo quando sei online e non richiederai pagine mentre sei offline allora il secondo metodo è il migliore. Se ridurre lo spreco di banda è la caratteristica più importante di JunkBuster allora il primo metodo è migliore perché eviterà che WWWOFFLE scarichi spazzatura.
Il programma WWWOFFLE è stato scritto da by Andrew M. Bishop (amb@gedanken.demon.co.uk) nel 1996,97,98,99,2000. C'è una home-page di WWWOFFLE sul World Wide Web, disponibile dall'home-page dell'autore a http://www.gedanken.demon.co.uk/ . Questa è mantenuta aggiornata con le novità sul programma, così come vengono rilasciate nuove versioni. Un programma iniziale scritto dallo stesso autore in perl è stato usato per un certo periodo, ma ci si è resi conto che le funzionalità di quella versione erano insufficienti, eccetto che per un uso limitato. Il lavoro sul programma WWWOFFLE in sè è iniziato nelle vacanze di Natale del 1996, inizialmente come un miglioramento della versione in perl. Dopo il rilascio della versione 0.9 beta all'inizio di Gennaio 1997, è nato un forte interesse che ha portato al rilascio della versione 1.0 più tardi quello stesso mese. Seguirono molte versioni fino a Dicembre dello stesso anno, quando fu rilasciata la versione 2.0. Questa conteneva molte nuove grandi caratteristiche (come FTP) e includeva una riscrittura di buona parte del codice per renderlo più facile da mantenere e affidabile, inclusa la modifica completa del formato della cache. La versione 2.1 fu rilasciata a Marzo 1998 con alcune nuove caratteristiche, la versione 2.2 a Giugno 1998 con altre caratteristiche e la versione 2.3 ad Agosto 1998 con ancora più caratteristiche. Ancora la versione 2.4 con nuove caratteristiche fu rilasciata a Dicembre 1998 e la versione 2.5 nel Settembre 1999 La versione Win32 del programma è stata resa possibile dalla versione beta-20 del kit di sviluppo Cygwin alla fine di Ottobre 1998, quando fu rilasciata la versione 2.3e di WWWOFFLE. Le versioni 2.4b e 2.5a di WWWOFFLE sono state rilasciate anche per Win32 sebbene nessuna di esse funzioni totalmente su parecchie piattaforme a causa di incompatibilità. Il programma WWWOFFLE può essere liberamente distribuito in accordo con i termini della GNU General Public License (guarda il file `COPYING').
Ci sono tre mailing list disponibili per WWWOFFLE. Ci si può iscivere in due modi diversi - nella pagina degli utenti di WWWOFFLE e via e-mail. wwwoffle-announce Per annunci sulle nuove versioni di WWWOFFLE. wwwoffle-users Per discussioni sulle caratteristiche di WWWOFFLE, escluse quelle specifiche di un sistema operativo. wwwoffle-win32 Per discussioni su WWWOFFLE in sistemi Win32. La prima è solo per annunci dall'autore di WWWOFFLE, non sono ammesse discussioni su di essa. Le ultime due sono aperte all'invio dai membri della lista e altri che non sono iscritti. Per sottoscrivere via email, invia un messaggio a majordomo@gedanken.demon.co.uk con il messaggio 'subscribe <group-name>' nel body, p.e. 'subscribe wwwoffle-announce'.
Per e-mail, inviale a me a amb@gedanken.demon.co.uk e metti WWWOFFLE da qualche parte nella riga del subject. Puoi anche segnalare bug o fornire commenti attraverso il form di feedback nella home-page di WWWOFFLE sul World Wide Web accessibile da http://www.gedanken.demon.co.uk/ . Prima di fare questo, dovresti controllare la FAQ e la pagina web di WWWOFFLE per vedere se la risposta è lì. Se non c'è e vuoi segnalarmelo, allora sarebbe d'aiuto se tu potessi riprodurre l'errore, in particolare nel caso avviassi wwwoffled come 'wwwoffled -d 5 -c wwwoffle.conf', catturando l'output di debugging per la sessione che ha generato l'errore.