Section 0 - なぜ私の質問はこの FAQ にはないのか？
Section 1 - WWWOFFLE がすること (しないこと)
Q 1.1 WWWOFFLE は http、ftp、finger、https、gopher、... をサポートしますか？
Q 1.2 WWWOFFLE は UNIX 以外のシステムで動作しますか？
Q 1.3 WWWOFFLE のページで ... が生成されるように変更を加えてくれませんか？
Section 2 - イントラネットで役立つように WWWOFFLE を利用するには
Q 2.1 WWWOFFLE プロキシはローカルホスト以外のクライアントからアクセスできますか？
Q 2.2 なぜリモートクライアントは WWWOFFLE プロキシにアクセスできないのですか？
Q 2.3 リモートクライアントがたどれないリンクがあるのはなぜですか？
Q 2.4 マルチユーザ環境下の WWWOFFLE に関するセキュリティ問題には何がありますか？
Section 3 - WWWOFFLE がうまく動作しないときには
Q 3.1 WWWOFFLE を使わなければ問題ないのですが、WWWOFFLE を使うと私のブラウザが空のページを表示するのはなぜですか？
Q 3.2 WWWOFFLE を使わなければ問題ないのですが、WWWOFFLE があるホストを見つけることができないのはなぜですか？
Q 3.3 なぜ私のブラウザはブラウジング中に "Connection reset by peer" と言うのですか？
Q 3.4 なぜ FTP サーバ上のリンクをたどると、間違ったサーバに行こうとするのですか？
Q 4.1 なぜ私のブラウザはアプレット XYZ を始めれないのですか？
Q 4.2 ユニコードを用いたアプレット名はサポートされていますか？
Q 4.3 なぜ私の Netcape ブラウザは trustProxy セキュリティ例外を引き起こすのですか？
Section 5 - WWWOFFLE の文書化されていない機能
Q 5.1 どうしたら最後のオンライン時にダウンロードされたモニタページを見ることができますか？
Q 5.2 正規の間隔でページの再帰的取得をするにはどうしたらよいですか？
Q 5.3 ユーザが index にアクセスするのをどうしたら止めれますか？
Section 6 - WWWOFFLE に関するさらなる情報
Q 6.1 WWWOFFLE は誰が、いつ、なぜ書いたのですか？
Q 6.2 どんな WWWOFFLE のメーリングリストが利用できますか？
Q 6.3 WWWOFFLE に関するバグはどのようにして報告すればよいのですか？
そのいくつかはサポートされていて、いくつかはサポートされていません。
http : はい
WWWOFFLE のオリジナルバージョンは http のみをサポートしていました。
ftp : はい
バージョン 2.0 以降は ftp URL をサポートしています。
finger : はい
バージョン 2.1 以降は finger をサポートしています。これはプロキシ処理
の標準的なプロトコルではありませんが、それが有効に実行されえない理由は
見当たりません。
https : はい
バージョン 2.4 以降は Secure Socket Layer (SSL) 接続の透過的プロキシ処
理をサポートしています。それには https プロトコルも含まれます。
gopher : いいえ
これは WWW が実際に利用されるようになって、人気のなくなったプロトコル
です。これをサポートしたブラウザで見ることから、それは不可能なことと思
われます。ただその需要も限られたものでしょう。
For example DOS / Win3 / Win95 / WinNT / OS/2.
UNIX = はい
このプログラムは UNIX 向けに設計され、最初に書かれたバージョンも UNIX
用でした。そのため各種 UNIX の多くで動作するはずです。なお Linux、
SunOS 4.1.x、Solaris 2.x、*BSD での動作は確認しています、
DOS/Win3 = いいえ
このプログラムは DOS 向けには設計されていません。DOS のファイル名の制
限や、このプログラムの特徴であるマルチプロセス処理のために、DOS/Win3
での利用はできません。
Win95/Win98/WinNT = はい
このプログラムの Windows 32-bit バージョン は、Cygwin デベロップメント
キットが提供する MS Windows 用 UNIX システムコールライブラリのおかげで
利用できるようになりました。
OS/2 = たぶん
私は Cygwin の製品と同等の OS/2 向けのものは知りません。もしそれが存在
するならば、上記の Windows 95 / Windows NT と同じく移植することは可能
でしょう。
この質問は何度もなされてきました。WWWOFFLE が生成するウェブページ上で Javascript や、イメージ、さまざまな色などを扱いたい人がいるのです。 バージョン 2.2 からWWWOFFLE 自身が生成するウェブページ全てがカスタマイズできる ようになりましたので、このことはもはや問題ではなくなっています。 このことは、背景色やフォントサイズなど全てがお好みに合わせて変更できることを意 味しています。これをどのように行なうかについては、/var/spool/wwwoffle/html/messages ディレクトリを見て、README ファイルを読んでください。
はい、できます。こちらは最初から簡単にできるようになっています。 そのクライアントは、wwwoffled プログラムが動作しているサーバに接続できるコン ピュータならば、どんな種類のものでも結構です。必要なことは、クライアントのコン ピュータが、そのサーバにネットワークでつながっていること、WWWOFFLE プロキシに アクセスできるよう設定できるブラウザを持っていることのみです。
wwwoffle.conf ファイルのデフォルトの設定では、ローカルホスト以外の全てのクライ
アントがプロキシにアクセスできないようになっています。それらのクライアントがプ
ロキシにアクセスできるようにするには、wwwoffle.conf ファイルを以下のように編集
して、その新しい設定を読み込ませる必要があります
設定ファイルの AllowedConnect セクションには、WWWOFFLE プロキシへの接続を許可
されるホスト一覧を記述します。それらの名前は接続が確立したときに WWWOFFLE が得
る名前と比較され、そのアクセスが許可ないし拒絶されます。この一覧の各項目ではワ
イルドカードマッチングの形式も利用できますが、extra name lookups は実行されま
せん。
例えば プライベート IP アドレス空間 192.168.*.* をイントラネットとして利用しいる場合、
設定ファイルの AllowedConnect セクションは以下のように記述します。
AllowedConnect
{
192.168.*
}
このように設定すると、この一連の IP アドレスの全ホストに WWWOFFLE プロキシへの
接続を許可します。
Some of the links that are generated in the web pages that come out of the
WWWOFFLE proxy need to point to other pages on the proxy.
WWWOFFLE プロキシから取り寄せたウェブページ上のリンク
プロキシ上の他のページを
To be able to do this
the name of the host running the proxy needs to be specified in the LocalHost
section of the configuration file.
For example if the computer running the WWWOFFLE proxy is called www-proxy then
the LocalHost section of the configuration file would look like this.
LocalHost
{
www-proxy
localhost
127.0.0.1
}
The first of the names is what is used by WWWOFFLE to generate these links. The
others are used for servers that do not get cached by the proxy.
Security is a feature that I have considered to some extent when writing WWWOFFLE although it has not been one of my biggest concerns. The issues are listed below. For the Win32 バージョン it should be noted that on Win95/98 there is not the user level security that is provided by UNIX. It is not possible therefore to create files that are readable by WWWOFFLE and not by other users. The security features that are present in WWWOFFLE are therefore inapplicable to these systems. Configuration file password This file can have a password specified in it in the StartUp section that is used to limit access to the control features of WWWOFFLE. If set this password must be used to put WWWOFFLE online, put it offline, purge the cache, stop the server, edit the configuration file etc. If you have set a password then you should also make the file readable only by authorised users. The password is sent as plain text when using the wwwoffle program to control the wwwoffled server. The encryption used for the web page authentication is trivial. Proxy Authentication With the ability to be able to control access to WWWOFFLE using the HTTP/1.1 Proxy Authentication method, there is the added security risks of this. It is basically the same as for the configuration file password, the usernames and passwords are in plaintext in the configuration file and the password is send to the server using the same trivial encryption method. WWWOFFLE server uid/gid The uid and gid of the wwwoffled server process can be controlled by the run-uid and run-gid options in the StartUp section of the configuration file. This uid/gid needs to be able to read the configuration file (write is not required unless the interactive edit page is used) and have read/write access to the spool directory. If this option is used then the server must be started by root. Deleting requested URLs Only the user that makes a request for a page can delete that request, and then only when the deletion is done immediately. This is because a password is made by hashing the contents of the file in the outgoing directory. This means that read access to this directory must be denied for this to be secure. The built in web server This is a very simple server and will follow symbolic links, as a security feature only files that are world readable can be accessed. They must also be in a directory that the wwwoffled server can read. A check is not made for each directory component so world readable files in a directory readable only by the uid that runs wwwoffled are not safe. Accessing the cache There is in general no problem with allowing users access to the cache provided it is read only (but see URLs with password below). The only concern is that if purging is done using the access time of the files then running grep on the cache will spoil this. URLs with Passwords The URLs that use usernames and passwords need to be stored in the cache. For simplicity they are not hidden in any way. This means that any URL that uses a username/password in it can show up in the log file (with Debug or ExtraDebug levels only). The files in the cache also contain the username/ password information and should be made inaccesible to users for that reason.
When using a browser to visit a web-page nothing is returned when WWWOFFLE is used as a proxy but when the site is accessed directly without WWWOFFLE the page is visible. This can have a number of causes (all reported to me or tested myself): a) The web server that you are accessing requires the User-Agent header. If it is not present or set to an uncommon value (not Netscape or IE) then it returns an empty page In this case if you have the CensorHeader configuration file section set to remove the User-Agent header then you should either not censor this header line or set a replacement string that is acceptable. b) As above, but it does not matter what the value is for it to return a non-empty page. The solution is the same except that any User-Agent string can be used. c) The web server uses cookies to maintain state. This is common on sites that are more concerned with form than content, often without warning. d) The browser and server are trying to use HTTP/1.1 extensions that WWWOFFLE is ignoring.
There are two possible reasons for this. 1) A Non-authoritative DNS server. 2) A change in the DNS server configuration since wwwoffle was started. When WWWOFFLE looks up a hostname it uses the standard UNIX library (libc) function call gethostbyname(). This will only return the host information if the name that it receives from the domain name server (DNS) is authoritative. A non-authoritative answer is not returned, but an error status is set. Large browser projects (Netscape in particular) will use a non-authoritative answer if one is available. This means that it can access sites that are not available to WWWOFFLE. The source code for doing this is not obvious and requires quite low level functions in the name resolver library (libresolv). This problem only happens when the name server that you are using has poor connectivity to other name servers or some other name resolving problem. If possible the solution is to use a different name server, or complain to the manager of the one that you do use. [If anybody has source code for non-authoritative name lookups please tell me.] The other possible reason is that the DNS server that was configured when WWWOFFLE was started is no longer valid. This would happen for example if the file /etc/resolv.conf was changed after wwwoffled was run. This is not a WWWOFFLE only problem, but will affect any (most) programs that use name lookups. The reason is that the name lookup part of the standard UNIX library (libc) is initialised when the program is first started. When the name lookup is performed later it will still use the same configuration that was in place when the program was first started. This may happen without you being aware of it since some of the user friendly PPP setup programs will change the /etc/resolv.conf file depending on which ISP you are connecting to.
このことは、あるページに Netscape を利用してアクセスしたときに起こります。その 原因は分かりませんが、この問題は WWWOFFLE を使っているときにのみ起こり、直接接 続を行なう場合は起こりません。 [この (Netscape に特有の) 問題は、WWWOFFLE のバージョン 2.2c で修正できたと思 いますが、もし荘でない場合があったときには、私にお知らせください。]
If there is a directory called '/dir' on an ftp server and you load the page 'ftp://server/' you get a directory listing that includes a link to '/dir'. Following this link should take the browser to 'ftp://server/dir/', but on some browsers it goes to 'ftp://dir/' instead. I think that this behaviour is due to the browser and not WWWOFFLE. If you went to 'http://server/' and followed the link to '/dir/' then you would expect to go to 'http://server/dir/' and not to 'http://dir/'. This is just common sense. Why the browser is different for ftp than http I am not sure. [This should be fixed in バージョン 2.1 of WWWOFFLE, so is not really applicable to this バージョン of the FAQ]
[Walter Pfannenmueller <pfn@online.de> writes:] I suppose you have enabled java support. Your Browser says something like "Can't start Applet XYZ.class". Check if the file has been successfully downloaded by WWWOFFLE. If the file is accessible, open a java console (your browser should provide something like that) and get more details on the problem. Probably it's a security - violation. Every Browser has it's own SecurityManager class and you should consult the manual how you can lower these restrictions. If your applet however tries to get in contact with some server functionality (servlets, RMI, CORBA), we are at the end of the possibilities of an offline reader.
[Walter Pfannenmueller <pfn@online.de> writes:] I don't know. I transform those names to UTF8 encoding and the rest depends on what your filesystem or the host filesystem does with it. Java compilers do have problems with unicode, too, even though it should be supported. I'd appreciate any information that helps enlighten the dark. I'd like to know how to code Unicode to UTF8 transformation. The implementation in javaclass.c looks somehow awkward.
[Walter Pfannenmueller <pfn@online.de> writes:]
The error message should be
Could not resolve IP for host ... See the trustProxy property.
The Netscape Browser tries to verify the applets source host IP address.
While offline this is not possible. Therefore you have to persuade
the Browser to trust the proxy. To do this you have to find the preferences
file preferences.js on UNIX or prefs.js on Windows. Edit the file,
even though it says "don't edit" and insert the line
user_pref("security.lower_java_network_security_by_trusting_proxies", true);
somewhere. be sure to have closed all browser windows, because the
preferences file will be overwritten on closing. This should work for
all Netscape 4.0x and 4.5.
For more information have a look at
http://developer.netscape.com/docs/technote/security/sectn3.html
もっとも簡単な方法は、モニタウェブページインデックスに移動して、そのページを "Access Time" でソート (http://localhost:8080/index/monitor/?atime) することです。各ページはモニタされるときにアクセスされるので、もっとも最近にモ ニタされたページはこの一覧の上位にあります。
そのためには、再帰取得オプションとモニタオプションを併用します。再帰取得インデッ クス (http://localhost:8080/refresh-options/) で希望するページとオプションを設 定してボタンを押せば、そのリクエストが記録されたことを伝えるページが表示されま す。そこにはそのリクエストのモニタを可能にするためのリンクがありますので、それ をたどって通常モニタページ (http://localhost:8080/monitor-options)へ移動してく ださい。ただ入力フォームの URL は既に埋められています。
ユーザによる各 index へのアクセスを禁止するには、設定ファイルの DontGet セクショ
ンを用います。
DontGet
{
http://localhost:8080/index
}
指定するホスト名のチェックが行なわれるように、そのホスト名が LocalHost セクショ
ンの一番最初に記述されたものであることは確認しておかなければなりません。
WWWOFFLE プログラムは、Andrew M. Bishop (amb@gedanken.demon.co.uk) によって 1996、97、98 年に書かれました。. ワールドワイドウェブ上には WWWOFFLE ホームページがあり、http://www.gedanken.demon.co.uk/ にある作者のホームページを経由して利用できます。こちらでは、新しいバージョンが 利用できるように、このプログラムに関する最新ニュースが公開されます。 しばらくの間は、同じ作者によって prel で書かれていた初期のプログラムが使われて いましたが、小規模な利用以外では不十分だったこのバージョンの拡張版がリリースさ れました。WWWOFFLE プログラム自体の開発は、1996 年のクリスマス休暇に、初めはこ の perl バージョンを改良するハックから始まりました。 1997 年 1 月初めにベータバージョン 0.9 がリリースされた後も、興味深い成果がた くさんあり、それは同じ月にリリースされたバージョン 1.0 に取り込まれました。バー ジョン 2.0 がリリースされた同じ年の 12 月までは、たくさんのバージョンが引き続 いてリリースされました。バージョン 2.0 には (FTP のような) 大きな新しい特徴が さまざま実装され、また、プログラムの維持とビルドを用意にするためにかなりの部分 のコードが書き直され、キャッシュのフォーマットも完全に変更されました。1998 年 3 月には幾らかの新しい機能を備えたバージョン 2.1 がリリースされ、1998 年 6 月 にはより多機能なバージョン 2.2 が、1998 年 8 月にはさらに多機能なバージョン 2.3 がリリースされました。 このプログラムの Win32 バージョンは、WWWOFFLE のバージョン 2.3e がリリースされ た 1998 年 10 月末に、Cygwin デベロップメントキット のバージョン beta-20 によっ て作成可能になりました。 WWWOFFLE プログラムは、GNU 一般公有使用許諾の条件にしたがって自由に配布できま す。 (`COPYING' ファイルをご覧ください。)
現在 WWWOFFLE 用に 四つのメーリングリストが利用できます。これらを購読するには
二つの方法があります。- WWWOFFLE ユーザーズウェブページ上で購読を申し込むか、
電子メール経由で購読を申し込んでください。
wwwoffle-announce WWWOFFLE の新バージョンに関するアナウンス用
wwwoffle-beta-announce ベータテスタ向け WWWOFFLE 新バージョンのプレアナウンス
用(WWWOFFLE のテストに時間を割いていただける方だけが購
読してください。).
wwwoffle-users WWWOFFLE の特徴についての、特定のオペレーティングシステムに
依存しない議論用
wwwoffle-win32 Win32 システム上の WWWOFFLE に関する議論用
最初の二つは WWWOFFLE の著者からのアナウンスのみが流れ、そちらで議論をすること
はできません。残りの二つはこのメーリングリストのメンバーや、購読していない他の
方が自由に投稿できるものです。
電子メールで購読を申し込む場合は、'subscribe wwwoffle-announce' のように本文に
'subscribe <group-name>' と書いたメッセージを majordomo@gedanken.demon.co.uk
に送ってください。
By e-mail, send them to me at amb@gedanken.demon.co.uk and put WWWOFFLE somewhere in the subject line. You can also report bugs or provide comments via the feedback form on the WWWOFFLE home-page on the World Wide Web accessible via http://www.gedanken.demon.co.uk/ . Before doing this, you should check the FAQ and the WWWOFFLE web-page to see if the answer is there. If it is not and you want to report it to me then it helps if you can reproduce the error, in particular if you start wwwoffled as 'wwwoffled -d5 -c wwwoffle.conf' and capture the debugging output for the session that shows the error.