A_single_file_wiki_wifky2.png

掲示板 Part-VIII

iyahaya 長くなってまいりましたので、改頁しました。 (2007/11/10 20:11:31)

worry 大学の講義で紹介されて利用させていただいています。
そこで1つ質問です。amazon.plを使ってwiki上で書籍の紹介をしたいと思っているのですが、<<amazon ASIN番号 {|left|}>>としても書影が左に寄りません。マニュアルを見る限りでは、寄るはずなんですが・・・。どこを変えれば、左によるのでしょうか? (2007/11/26 03:22:56)

worry 連投すいません。今wikiで使っているCSSは「CSS_quiet_black」です。 (2007/11/26 03:31:26)

iyahaya うぅむ、その組合せだと、センタリングや右寄せにはならないはずなんですが…。left オプションだけでは、alt="left" という属性が img タグにつくだけなので、((amazon〜)) を外側から囲むタグのセンタリングや右寄せ指定の方が優先されているのかもしれません。試しに CSS のページの img.amazon{…} という行がありましたら(なかったら追記いただいて)、中括弧の中に「float:left;」をいう文を追記してみていただけますでしょうか? あるいは、もしかしてサイドバーの中に入れるという意味でしょうか?(その場合は、すみません。未対応です)
(2007/11/26 19:46:51)

usuragi Basic認証付きURL(http://user:pass@host.domain.com/wifky.pl等)で呼び出された場合に、内部リンク先のURLから"user:pass@"の部分を削除できないでしょうか?
というか、デフォルト状態でも削除するのが適切ではないでしょうか? (2008/02/23 12:25:50)

iyahaya wifky 自身としては削除するも何も、相対パスでしか内部URLを扱っておらず、HTMLソース内のURLにuser:pass@が含まれることはありません(ブラウザで HTML ソースをご確認ください)。それゆえ、マウスをリンクにオーバーラップさせた時にステータスバーに表示させる URL に対し、Firefox がホスト名部分を補完させているだけかと思われます(Opera や w3m では :pass 部分を消す動作をしてくれます。IE はそもそも認識しません)。
「ホスト名」を敢えて明示して、Firefox が補完しないようにするということは可能ですが、そういう処理が欲しいということでしょうか? (2008/02/23 19:37:15)

usuragi なるほど。ソースを見ずに軽率に質問してしまいました。失礼しました。 (2008/02/23 23:29:15)

iyahaya いえいえ、セキュリティーに配慮した提言は歓迎ですので、気軽におっしゃっていただいてよろしいかと思います。ホスト名明示についても「やはり、どうしても要るだろう、常識的に考えて」ということであれば、次のリリースに組込みます (ただ、サーバによってはホスト名が取れないケースがあるかもしれないので、そこは一工夫が要るかなと思ってます) (2008/02/24 13:53:44)

worry 以前、amazon.plについて質問おいて、返信をせず失礼いたしました。書影の処理はご指摘いただいた方法で解決しました。ありがとうございました。
さらに質問なんですが、headerをmainから分離するために「設定「header in mainframe」のチェックを ON する」とありますが、そのチェックボックスがToolsの中に見つけられませんでした。
この場合、どのようにすれば分離ができるでしょうか? (2008/03/04 15:45:43)

iyahaya すみません。そのオプションは 1.1 にて廃止し、header 部は必ず main部に入るという tDiary互換のスタイルに統一しています(常に header in mainframe が ON になっているのと等価)。ヘッダ部をブラウザ幅いっぱいにまで広げるには、http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=CSS_wideheader のように CSS の方で一工夫いただけますでしょうか。 (2008/03/05 01:44:53)

katsuaki 1.2.0.0を使用させていただいております。1ページに書き込む文字数が多くなるとInternal Server Errorが出るようなのですが、何か制限があるのでしょうか?あるいは「ソースのここを修正すれば直る」というような個所があればご指摘ください。 (2008/10/12 11:29:53)

iyahaya なんと! 本体はページテキストに特にサイズの制限を設けていません。Perl 本体のバージョンと、どれくらいの文字数くらいで発生するかを教えていただけないでしょうか? (2008/10/12 20:39:00)

iyahaya 当ページの 1.2.0 で試してみましたが。4096文字程度はいけるみたいですね。環境要因かもしれません。 http://wifky.sourceforge.jp/cgi-bin/testbed/wifky1200.cgi?p=(2008.10.13)+%CA%B8%BB%FA%BF%F4%A5%C6%A5%B9%A5%C8 (2008/10/13 00:46:40)

katsuaki Perlのバージョンは5.00503です。文字数は正確には測れませんでしたが、ファイルサイズが820KB程度でした。更新時ではなく表示時にエラーになるようです。 (2008/10/13 21:42:11)

iyahaya 一文章で 820「キロ」バイトですか? 820 バイトではなくて?
とすると、多分もうメモリ的な制約にひっかかってるのではないかと思われます。@nifty では、添付ファイルも500KBくらいでアウトでしたし… 週末にまた再現テストなど実施してみますが、対応は正直難しいかもしれません。 (2008/10/14 22:06:13)

katsuaki wifky側で特に制限を設けていないとのことで、環境の問題のようですね。ありがとうございました。 (2008/10/18 10:18:25)

noname wifkyを試用してみたのですが、なぜ出力されるHTMLの頭にXML宣言がついているのでしょうか?XML宣言はXML(XHTML含)として出力している場合にのみ必要で、HTMLではそもそも必要ありません、と言うか付けてはいけないことになっています。次回バージョンアップ時に改善されることを願います。 (2008/10/23 14:09:46)

iyahaya わかりました。はずします (2008/10/23 20:24:03)

iyahaya >>katsuakiさん
すみません。後から確認したところ「登録時」には全体の 1MB の上限を設定していました。「表示時」は特に制約をつけていませんが… 念の為、外しておきます。 (2008/10/23 20:27:30)

katsuaki 対応ありがとうございます。 (2008/10/26 10:04:33)

himajin はじめまして、この度puppylinux4.1.2に1.3.3をインストールしてみました。
httpサーバーは”Hiawatha”というもので、Perlは5.008008です。
設定は出来るのですが、ページの新設、編集後の保存が以下のエラーになります。
Insecure dependency in mkdir while running setuid at /root/httpd/hiawatha/wiki/wifky.pl line 1172.



(2008/12/11 22:29:39)

himajin その他、ファイルの添付でもエラーになります。
どうもmkdirがらみでエラーになるようです。 (2008/12/11 23:46:44)

iyahaya ご報告ありがとうございます。手元で再現できる環境がないので、推測ベースとなりますが、どうも強いセキュリティー保護が効いている環境では「ゆるいパーミッション」で mkdir したりすると怒られるように見えますね(このディレクトリ自体はロックのために作っていて、すぐ削除されるものなので、緩いパーミッションでも実際問題ないはずだったのですが)。

とりあえずの回避策ですが、試しに 1172行目の mkdir の第二引数で 0777 となっている箇所を 0700 としてみていただけないでしょうか。これで必ず直るかどうかは分からないので申しわけありませんが、よろしくお願い致します。 (2008/12/12 00:38:54)

himajin puppyのperlは軽量化のためモジュールを削っているのですが、何か足りないモジュールがあるのでしょうか? (2008/12/12 00:41:35)

iyahaya いえ、wifky はモジュールは一つも必要としません。perl の実行ファイルだけでも稼働します。 (2008/12/12 00:44:56)

himajin 回答有難うございました。試してみましたが、変化ありませんでした。 (2008/12/12 00:45:27)

himajin ちなみに wifky.dat dirは出来ています。 (2008/12/12 00:47:55)

iyahaya どうも、http://perldoc.jp/docs/perl/5.6.1/perlsec.pod にある、taint mode という状態で Perl が稼働しているようです。wifky はブラウザから入力された文字列をベースにファイル名を生成しているのですが、それが汚染された文字列を内部に持ち込んだと認識されてしまっているようです(実際は unpack で符号化しているので、問題ないんですが)。 (2008/12/12 00:56:01)

iyahaya wifky は今まで taint-mode での稼働テストをやったことがないため、すぐの対応は難しいかもしれません。ただ、開発者としては対応はしておきたいところです。どこでも稼働するを売りにしている以上は…。
一番てっとり早いのは、taint-mode とならないよう、setuid しないようにすることですが…。ちなみに wifky.pl のファイルのパーミッションはどのようなものになっているでしょうか? (2008/12/12 01:00:09)

iyahaya 症状をこちらで再現させることができました。対応できると思いますので、お時間いただけますでしょうか。(週末がんばります) (2008/12/12 01:03:20)

himajin 0755です。
# ls -l
total 125
drwxr-xr-x 2 root nobody 1024 2008-12-12 01:03 wifky.dat
lrwxrwxrwx 1 root root 15 2008-12-12 00:38 wifky.pl -> wifky_usrbin.pl
-rwxr-xr-x 1 root root 61626 2008-10-04 09:42 wifky_local.pl
-rwxr-xr-x 1 root root 61620 2008-12-12 01:04 wifky_usrbin.pl
(2008/12/12 01:05:01)

himajin うまく動けばPuppyLinux日本語版にdidiwikiの代替として入れたいと思います。
(2008/12/12 01:09:08)

himajin おっと↑は間違い。探してるのはblogでした。
(2008/12/12 01:15:40)

でも同様のことが出来るようにも見えますね。 (2008/12/12 01:27:52)

iyahaya すみません。次のバージョンを試してみていただけますでしょうか。仮対応してみました。http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=taint+version (2008/12/12 02:19:02)

iyahaya すみません。まだ、chmod 系のエラーが出てるようなので、↑は無視してください。 (2008/12/12 12:46:01)

himajin うまく動くようです。pluginmgrは不明。
(2008/12/12 23:13:28)

pluginmgr.pl他nikky.pl等も問題なく動いているようです。 (2008/12/12 23:27:47)

iyahaya 凍結処理に問題があるみたいなので、それが直り次第、正式版をリリースいたします。m(_ _)m (2008/12/13 02:23:03)

himajin freezのエラー 確認しました。 (2008/12/13 09:17:45)

iyahaya 正式版の方、リリースしました。トップページからダウンロードして、お試しいただけますでしょうか。 (2008/12/13 23:53:49)

himajin 問題ないようです。有難うございました。何か気がついたら報告します。 (2008/12/14 01:46:54)

ところで、◇文法【1】の中で使われている viewsource プラグイン?について解説していただけませんか? (2008/12/14 01:53:00)

himajin  1.3系でアーカイブモードの時、signinせずにバックアップを削除出来るようですが、これはまずい仕様だと思うのですが..... (2008/12/14 11:45:37)

というか 凍結 されません。freezにチェックしても次回編集時無効になっています。有効にしてsubmitし、signoutsして一般ユーザーになっても編集できます。 (2008/12/14 12:16:17)

iyahaya 「これはまずい仕様だと思うのですが」― 仕様ではなく、不具合です。少々お待ちください。 (2008/12/14 12:20:53)

iyahaya 確認です。(こちらで再現しないもので)
(1)「編集できます」― すみません。それは本文のことですか? 添付ファイル化されているアーカイブのことですか?
(2) アーカイブファイルのリストの横に「frozen」マークはつきますか?
(3)実行時にエラーの類は出ていないですか? (2008/12/14 12:35:31)

iyahaya もしかして、お使いの環境では chmod の使用が禁止されているなどはないでしょうか? もし、そうであれば、フラグとしてパーミッションの u±w を使っているので、wifky の凍結処理は使えません。 (2008/12/14 13:11:28)

iyahaya viewsource(ソース閲覧)プラグインは公開していませんでした。以下にダウンロードページと解説を記載しました。
http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=%5Bplugin%5D+%A5%BD%A1%BC%A5%B9%B1%DC%CD%F7%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3 (2008/12/14 13:43:09)

himajin ubuntuのapache2で動かしたところ、上記の不具合は起きませんでした。
もう少し調べてみます。 (2008/12/14 13:46:24)

iyahaya 環境の方、拝見しました。URLなどをご記入いただいたコメントは削除させていただきました。危険をおかしてまでのご協力感謝します。
見たところ、chmod が全然効いていないようですね。。これはウェブサーバか、OS設定?でプロテクトされている可能性が高いですね。。 (2008/12/14 13:52:44)

himajin A
(1)両方です
(2)つきません
(3)logを初期化して確認します。 (2008/12/14 13:57:17)

himajin ファイルのパーミッションは変更されるようです。
どうも原因はwebサーバーがroot権限で動いていることのようです。 (2008/12/14 15:28:28)

himajin そもそもPuppyLinuxでは、rootユーザーしかいないので、サーバーの設定も ServerId = nobody:nobody となっています。 (2008/12/14 15:32:47)

iyahaya こちらは動作するでしょうか? → http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=test-chmod (2008/12/14 15:34:55)

iyahaya 「ファイルのパーミッションは変更されるようです」― そのファイルの持主は root ですか? nobody ですか? また、その「変更」は wifky でさせたものですか? コマンドラインで変更しようとしたのでしょうか? (2008/12/14 15:54:16)

himajin user:root group:nobody chmod by wifky です (2008/12/14 16:18:19)

himajin test-chmod は 500 Internal Server Error になります。 (2008/12/14 16:32:47)

himajin tstchmod_usrbin.cgi.flag は作られません。 (2008/12/14 16:36:12)

iyahaya すみません。tstchmod_usrbin.cgi を置くディレクトリのパーミッションを書き込み可能にしてみていただけますか? (2008/12/14 16:49:58)

himajin 777になってます。 (2008/12/14 17:03:59)

iyahaya スクリプトの #! 行がおかしかったようです。画面にトレース状況を出すように改良した版を、http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=test-chmod
に置きましたので、お手数ですが、もう一度ご確認いただけますか。 (2008/12/14 17:10:07)

himajin 状況としては、パーミッションは変更できるが、書き込みフラグが立っていないファイルを編集.....ちょっと違うなアーカイブモードだから前のファイルを読み込みバックアップして、同じ名前の新しいファイルを書き込みフラグを立てて作り、読み込んだ内容を書き込んで保存。かな? (2008/12/14 17:17:12)

iyahaya パーミッションのうち u+w が凍結フラグそのものなので、パーミッションが変更できるのに、凍結フラグが変わらないということはつじつまがありません。考えられるのはパーミッションを読み込めない(凍結していることを認識できていない)のではないかということで、上記のテストをお願いした次第です。 (2008/12/14 17:26:31)

himajin 初回
try create flag-name ...ドーン
try flag test ...not exists
try create file ...success
tru stat...ドーン
tru chmod -w ...success
tru stat...ドーン

Permission=100444
です (2008/12/14 17:27:12)

リロードすると
try create flag-name ...ドーン
try flag test ...exists
tru stat...ドーン
tru chmod -w ...success
tru stat...ドーン

Permission=100444
です (2008/12/14 17:29:41)

himajin 以後変化ありません。 (2008/12/14 17:34:18)

iyahaya 失礼しました。「done」が NG ワードになっていたようですね。先程、解除しました。本来であれば偶数回目では

try create flag-name ...done
try flag test ...exists
tru stat...done
tru chmod +w ...success
tru stat...done

Permission=100666

となるはずなので、パーミッションの変更がやはり出来ていない、あるいは CGI でパーミッション情報を読み出せない…のいずれかのようです。 (2008/12/14 17:38:09)

himajin tstchmod_usrbin.cgiで出来ないのは書き込みフラグを”立てること”
かも、出来たtstchmod_usrbin.cgi.flagをコマンドラインから書込み可に変更してから、tstchmod_usrbin.cgiを実行すると書込み不可に変わります。 (2008/12/14 17:59:56)

iyahaya どうも Perlの「-w」演算子(書き込み可能かどうかをテストする演算子)が常に「真」を返している…としか考えられない状況です。wikfy は「-w ファイル名」の結果が偽であれば、それが凍結されていると判断します。上でテストしていただいた結果を見ると、パーミッションは確かに変わっているのに、-w 演算子がその結果に反映した結果を返していません。

もしかして、root で動作しているから、パーミッションに関係なく「(強制的にだが)書き込みが出来」という意味で -w が真を返しているということかもしれませんが…。 (2008/12/14 18:00:27)

himajin #ls -lで
-r--r--r-- 1 root nobody 5 2008-12-14 17:58 tstchmod_usrbin.cgi.flag
です。
(2008/12/14 18:14:59)

himajin お疲れでしょうから、今日はこのへんで (2008/12/14 18:23:50)

himajin 追伸 perl自身もroot権限で動いてるわけですよね...... (2008/12/14 18:31:02)

iyahaya 原因が分かりました。やはり root で Perl を実行させていたためのようです。root で動作している場合、たとえパーミッション上、444 となっていても、root であるから書き込みが可能なので -w は常に「真」になってしまうようです。

実験結果:

【root で実行させた場合】
# cat write_test.pl
#!/usr/bin/perl

for(@ARGV){
printf "%d %s\n",(-w $_),$_;
}
# touch ahaha
# touch ihihi
# chmod a-w ahaha
# perl write_test.pl ahaha ihihi
1 ahaha
1 ihihi
[root@LK1C_TIS root]# ls -l ahaha ihihi
-r--r--r-- 1 root root 0 Dec 14 18:51 ahaha
-rw-r--r-- 1 root root 0 Dec 14 18:51 ihihi

【一般 ユーザで実行させた場合】
$ cp ~root/write_test.pl .
$ touch ahaha
$ touch ihihi
$ chmod a-w ahaha
$ perl write_test.pl ahaha ihihi
0 ahaha
1 ihihi
$ ls -l ahaha ihihi
-r--r--r-- 1 hayama kame 0 Dec 14 18:52 ahaha
-rw-rw-r-- 1 hayama kame 0 Dec 14 18:52 ihihi

一番よいのは root 以外のユーザで実行させることですが…難しいでしょうか? その方がセキュリティー的にも望ましいと思われますが…
(2008/12/14 19:02:20)

iyahaya 対応してみました。また、お時間ある時にお試しいただけますでしょうか >> http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=exam-version (2008/12/14 20:01:23)

himajin うまくいきました。有難うございました。 (2008/12/14 20:28:15)

himajin  デバッグモードにしたところ

splice() offset past end of array at /root/httpd/hiawatha/wiki/wifky.pl line 1609.
on main::__ANON__ at /root/httpd/hiawatha/wiki/wifky.pl line 1609.
on main::ls_core at /root/httpd/hiawatha/wiki/wifky.pl line 1633.
on main::ls at /root/httpd/hiawatha/wiki/wifky.pl line 109.
on main::__ANON__ at /root/httpd/hiawatha/wiki/wifky.pl line 1719.
on main::plugin at /root/httpd/hiawatha/wiki/wifky.pl line 1795.
on main::preprocess_plugin at /root/httpd/hiawatha/wiki/wifky.pl line 1812.
on main::preprocess at /root/httpd/hiawatha/wiki/wifky.pl line 2000.
on main::block_normal at /root/httpd/hiawatha/wiki/wifky.pl line 1881.
on main::call_block at /root/httpd/hiawatha/wiki/wifky.pl line 1873.
on main::syntax_engine at /root/httpd/hiawatha/wiki/wifky.pl line 1436.
on main::print_page at /root/httpd/hiawatha/wiki/wifky.pl line 1318.
on main::template_callback at /root/httpd/hiawatha/wiki/wifky.pl line 1296.
on main::print_template at /root/httpd/hiawatha/wiki/wifky.pl line 1335.
on main::action_view at /root/httpd/hiawatha/wiki/wifky.pl line 59.
on (eval) at /root/httpd/hiawatha/wiki/wifky.pl line 24.

と出ました。exam版です。 (2008/12/15 18:04:02)

iyahaya 御報告ありがとうございます。それは ((ls -N))の N > ページの総数であるために出ている警告のようですね。デバッグモード時にメッセージが出る以外、特に害は無いので、それ自体は無視していただいてよろしいかと思います。 (2008/12/15 20:56:54)

himajin 了解しました。有難うございました。
(2008/12/16 00:49:28)

himajin 名前と コメントの間に空白が一つ欲しいですね。どこを直せばいいでしょうか (2008/12/16 19:10:36)

↑の書き込みを http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=%282005.07.09%29#p1 にしようとしたのですが出来ませんでした。 (2008/12/16 19:13:18)

himajin ところで、基本的に英語表記なのは世界進出の野望を秘めているからですか? (2008/12/16 19:20:02)

iyahaya 空白については別方面からも言われてますので、ちょっとお待ちいただければ、対応しますよ。
(2008/12/16 21:14:32)

iyahaya 文字コードをEUC-JPにしてる時点で世界はありません。表記が英単語なのは、日本語(EUC-JP)をソースに入れてしまうと、ユーザに#!行を編集いただく時に文字化けトラブルの元となるからです。もっとも、今のバージョンでは編集しないでいいように最初から#!/usr/bin/perl用と#!/usr/local/bin/perl用の2バージョン用意していますが、最初からそうだったわけではありません。 (2008/12/16 21:45:47)

himajin ディレクトリ名に日本語を通常使うことは無いので問題にならないと思うんですが?
ちなみに当方ではUTFー8で運用中です。
(2008/12/16 22:40:06)

iyahaya コンテンツが UTF-8 である事と、スクリプトに日本語が入っている事は話が別です。UTF-8 で運用するサイトは以前より存在しておりますので、コンテンツの文字コードを変えることができないと考えているわけではありません。 (2008/12/17 01:56:17)

iyahaya また、ソースについては #!行に日本語が入ることだけを懸念しているわけではありません。昨今は、優秀なエディタや FTP ツールが自動的に日本語文字コード変換することがありますし、逆に完全に Shift-JIS コードしか想定していないエディタも存在します。そういったツールの手で EUC-JP が含まれたソースファイルが触られた時に、予期しないコード変換・あるいはファイルの破損など発生する可能性が完全にゼロとは言い切れません。
wifky は導入の容易さを最優先していますから、そういった事故の可能性を完全に排除する意味で、ソースの中から日本語コードを排除しているわけです。 (2008/12/17 01:57:09)

himajin いつもお世話になっています。
気になることが2つ。
確信がある訳ではないのですが、どうも画像の表示が不安定な印象です。ブラウザのせいなのか、サーバーのせいなのか、登録した画像が表示されたりされなかったり。何度リロードしても表示されないことがあります。
もう一つ、設定ページの表示がCSSの影響を受けて表示がずれて、操作(設定)しにくい配置になることがあります。設定時にブラウザでCSSを無効にすれば操作は出来ます。設定ページ用にCSSを設定することは可能でしょうか? (2008/12/19 13:21:31)

iyahaya 画像は CGI 出力させていますので、もしウェブサーバ側でタイムアウトや出力量の制限をかけていたりしましたら、それにひっかかる可能性はあるでしょう。 (2008/12/19 15:21:45)

iyahaya CSS を分けることはできませんが、設定ページの時はページ全体が <div class="max">…</div> というタグで囲まれます。一方、一般ページでは、これが <div class="main">…</div><div class="sidebar">…</div>になりますので、それで表示分けできるかと思います。 (2008/12/19 15:30:33)

himajin 有難うございます。
設定ページの件はうまくできました。 (2008/12/19 16:21:23)

himajin ↑はCSS_wideheader適用時のことでした (2008/12/19 16:52:32)

himajin 20KB程度のjpgなのでそういうことは無いと思うのですが、もう少し調べてみます。
(2008/12/19 19:48:39)

iyahaya (1) 同一の画像が表示できたり、できなかったりしますか? それとも、画像によって、常に大丈夫な画像、それでない画像がありますか?
(2) アップロードした後のサーバ上の画像ファイル(ファイル名に「__」が含まれます)は、アップロード前の画像ファイルと内容が一致していますか?
(3) 画像でない「添付ファイル」のアップロード・ダウンロードはうまくゆきますか?
(4) (3)が一見うまくゆっている場合、アップロードした時とダウンロードしたファイルは内容が完全に一致していますか?

wifky の画像/添付ファイル出力の仕組みは実装してから3年経つ、それなりに実績のあるものです。それが動かないとなると、CGI経由でのウェブサーバのバイナリデータ出力に Apache などとは異なる点があると思われる…としか今のところ、言えません。
(2008/12/20 02:15:48)

himajin ubuntuno
ubuntuのapache2上では問題ないのでサーバー側の問題のようです。お騒がせしました。 (2008/12/20 05:46:36)

himajin 回答しておきます
(1)出来たり出来なかったりです。2つの画像を表示させているのですが、先の画像の方が表示されて後の画像が表示されない(大抵こうです)又は2つとも表示されない。順番を入れ替えても、後になった方が表示されない(先のときは表示された)
(2),(3),(4)後ほど確認します。 (2008/12/20 05:55:03)

iyahaya それはウェブサーバが同時に1リクエストしか応答しない(できない?)ようになっているということではないでしょうか? (2008/12/20 08:25:35)

himajin デフォルトの状態で2リクエストになっていました。4リクエストw受け付ける設定にしたところ改善されたように見えます。 (2008/12/20 10:24:42)

himajin この件がらみで気がついたのですが、添付した画像を表示させるのには
<<{hoge.jpg} と((hoge.jpg w h)) の2通りあるのですが(もっとある?) 後者の出力は
<img src="url;hoge.jpg" width="w" height="h">
となって alt属性が付きません。前者には付いています。 (2008/12/20 11:00:19)

himajin でもこれは more.pl に由来する現象で、本体の問題ではないですね。 (2008/12/20 11:04:20)

iyahaya 2リクエストならば HTML 本体を GET するのと、画像一つを GET することで、同時リクエスト数を消費し尽してしまうことになりますから、まぁ、当然の結果かと思われます。 (2008/12/20 14:12:58)

iyahaya more.pl はサンプルの詰め合わせみたいなもんですので、あんまり品質は期待しないでくださいw (2008/12/20 14:14:12)

|

Designed for @nifty.