えむけいさん、
確かにキャッシュファイルとして有効でした。
ただ現在の「デバイス名判定」では「デバイス」として認識しているわけではありません。その辺がちょっとおかしくて修正が必要なところです。
>それはともかく、デバイスの判定とは別に、実際にファイルを作る時にエラーになると __ をつけて再試行するようにしています。もっともそうやって作った __com3.gif はキャッシュファイルとして認識しないので、毎回そのファイルを作るという動作をするはずです。
今度は K:\cache\http\himawari.kix.or.jp\monolith\image を削除せずに http://himawari.kix.or.jp/monolith/image/com3.gif へアクセスしてみました。その結果、cache.logには
Sat Mar 11 06:44:21 2000 Hit: k:\cache\http\himawari.kix.or.jp\monolith\image\__com3.gif
trace.logには
----------------------------------------
<<< s=620: Sat Mar 11 06:44:21 2000 <<<
GET http://himawari.kix.or.jp/monolith/image/com3.gif HTTP/1.0
>>> s=300: Sat Mar 11 06:44:27 2000 >>>
GET /monolith/image/com3.gif HTTP/1.0
If-Modified-Since: Mon, 08 Dec 1997 11:01:54 GMT
Host: himawari.kix.or.jp
<<< s=300: Sat Mar 11 06:44:27 2000 <<<
HTTP/1.1 304 Not Modified
Date: Fri, 10 Mar 2000 21:45:49 GMT
Server: Apache/1.3.9 Ben-SSL/1.37 (Unix)
Connection: close
ETag: "1e8c4b-249-348bd3a2"
----------------------------------------
と記録されたので、どう考えても認識しているとしか思えないのですが…。
えむけいさん、
com3.gif は、WindowsNT/2000 で現状の判定法ではデバイスとはみなしません。
com3 や aux は読み取りアクセスでは普通のファイルと同じ様に存在しないというエラーを返すので。
prn, nul, lpt1 などは読み取りオープンできて GetFileType で判定できました。con はまた扱いが違うようで、さらに、Win95/98 だとまた状況が違うので、困ったものです。
それはともかく、デバイスの判定とは別に、実際にファイルを作る時にエラーになると __ をつけて再試行するようにしています。もっともそうやって作った __com3.gif はキャッシュファイルとして認識しないので、毎回そのファイルを作るという動作をするはずです。
というわけで、キャッシュとしてちゃんと使えていないので、それを含めて改善する予定でいます。
>com3.gif などのキャッシュの件、1.26b の仕様では、デバイス名を含むと判断されたURLはキャッシュされないはずです
もう一度テストしてみました。
1. Aboutでバージョン1.26bであることを確認。
2. %CacheRoot%\http\himawari.kix.or.jp\monolith\image から __com3.gif を削除。
3. telnetで http://himawari.kix.or.jp/monolith/image/com3.gif へアクセス(キャッシュの影響を避けるためブラウザは使わない)
で、%CacheRoot%\http\himawari.kix.or.jp\monolith\image に __com3.gif が作成されました。
デバイス名を含むと判断されていないのかとも思いましたが、それなら __com3.gif と名前が変形されるはずありませんし…。
えむけいさん、
com3.gif などのキャッシュの件、1.26b の仕様では、デバイス名を含むと判断されたURLはキャッシュされないはずです。
これはキャッシュファイルを作る前の判定が面倒なための当面の仕様で、近いうちにすべてキャッシュするように直すつもりでいます。
> 1.26bにしたらやはりcom3.gifとかがキャッシュされなくなってしまったようなのですが、どうしようもないのでしょうか?
と思ったのですがもう一度試してみたらちゃんとキャッシュされました。
ブラウザのキャッシュが悪さをしていたようです。
重ね重ねデマでご迷惑をおかけして申し訳ありません。
1.26bにしたらやはりcom3.gifとかがキャッシュされなくなってしまったようなのですが、どうしようもないのでしょうか?
>予約デバイス名で 400 になるのも今は判定の確認用なので、ちゃんとしたら 404 にしようかと思っていますが、どんなものでしょう？
そう思います。クラッカーに余計な情報を与えるべきではありません。
えむけいさん、
Win9x のプロクシの concon 対策 と WinNT/2000 の /予約デバイス名 対策 は、今日は時間がなくなってしまったので明日夜に出します。
プロクシの方は気にはしていたのですが、本体側でちょっと時間をとられて抜けてしまいました。
なお、WinNT系で /nul/nul などは 現状では 404エラーになります。文字通りそのようなファイルはない、なので。
予約デバイス名で 400 になるのも今は判定の確認用なので、ちゃんとしたら 404 にしようかと思っていますが、どんなものでしょう？
すみません、いまWindows98上でテストしてみたら /nul/nul も /lpt1/lpt1 もちゃんと弾きました。
ただし別の穴を発見しました。プロキシがconconのチェックをしていません。今度はWindows98上で実際に con/con で終わるURLをIE5に渡して落ちるところまで確認したので間違いないと思います。
これは単純にエラーにしてしまうとUNIXサーバ上のcom1.gifとかが取得できなくなってしまうので工夫が要りそうです。
conconバグの対策ですが、かなり不完全なようです。
/con/con は弾きますが、/nul/nul とか /lpt1/lpt1 とかcon以外のものを多段にしたときは通してしまうようです(ステータスコードが400ではなく404になる)。
あとWindows2000ですが、/com3 でhttpdが落ちました。これはconconとは関係なくてプロキシのときにも報告した予約デバイス名を開くとNT系で落ちるというバグだと思います。
Windows95/98 のいわゆる concon バグへの対応について
3月5日（日）に予定している次のバージョンで、concon バグへの対策を施します。
なお、あわせて、プロクシを https(SSL tunnel)に対応させ、他のいくつかのバグ対策をおこなうつもりです。