■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

read.cgi改良スレッド 2

730 :デフォルトの名無しさん :01/09/26 22:05
>>729
かちゅ〜しゃだけ。IEだとずれないのにかちゅ〜しゃだと
ずれるというのが直るに過ぎない。
IE5.5問題はフォントの設定をいじらないとダメ。

731 :デフォルトの名無しさん :01/09/26 22:41
>>720 を修正した。
ついでに、can_simplehtml()のバグを見つけたので修正。

732 :デフォルトの名無しさん :01/09/26 22:51
えっと、専用ブラウザ作者です
通信失敗したときのためにdat取得途中にもいったん保存したいと思ってるんですが、
datのサイズを計算するとき、\0も含めて\r\nまで数えれば計算合いますか??
それとも\r\nは含まず?

モバイル時、rawモードで一気に900近いレスを取得するのは難しいので・・・

733 :デフォルトの名無しさん :01/09/26 22:57
datの改行は\r\nじゃなくて\nです。
もし\r\nに見えてるとしたらお使いのライブラリか何かが
勝手に変換してるということなのでそのままでは絶対に
計算合いません。

それはそれとして、rawモードでも部分取得に対応したほうが
いいのだろうか。こういう意見もあるし。

614 :作者 本日のレス :01/09/26 01:16
つまり、最新50とか、10-30までとかいった読み方は考えていないということか。

734 :732 :01/09/26 23:00
失礼、\r\nは単純にそう思っただけです(^^;
実際には\nでしか判定してません

735 :デフォルトの名無しさん :01/09/26 23:31
5.24が各鯖にインストールされた模様。
SPECIAL_SETTINGが動作しているのを確認。

混雑時の設定は、22-03のようだから、
read2ch.hも合わせておいた方がいいかな。

736 :729 :01/09/26 23:32
>>730
Thanks.
やっぱりかちゅだけだったか……個人的には言語指定位入れといても
いいような気がするけど、まぁ全部省略だろうな、ここは(何)。

737 :デフォルトの名無しさん :01/09/27 02:54
READ_KAKO/READ_TEMPには問題がいくつかある。

第一に、READ_KAKOがdefineされていないときには
READ_TEMPをundefしているが、
これはプログラム上の都合であって、動作としては望ましくない。
実際には、kako/はhtmlを読めばよいので閲覧禁止にしてあっても、
datでしか読めないtemp/は(特にdat直読みが禁止されると)
閲覧を許可するという状況は十分に考えられる。
逆は考えにくいので、逆になっていればよかった。

次にREAD_KAKOをrawmodeでも一律に扱っているが、これはどうだろうか。
ツールを使っていても、倉庫送りにされたログを読む場合には
結局datに直にアクセスすることになる。
大半が取得済みのdatの場合は、圧縮をあきらめて差分取得する
ことになってしまうし、
全体を新規取得する場合でも、圧縮はmod_gzipとその設定次第となる。
何より、直読み禁止になったらどうしようもない。
「rawmodeのみ過去ログ取得を許可する」conditionを設けるべきだと思う。

さらに細かい点を指摘すると、read.cgiで過去ログを読む事を前提とするなら
過去ログのdatがどこにあるかなど、ユーザーには関係ない。
kako/とtemp/でわけて指定させる必然性は全く無い。
もっとはっきり言えば、READ_KAKOが有効な場合には、
key=999999999を指定するだけで透過的に過去ログにアクセスできる方が
はるかに望ましい動作といえる(もちろん、書きこみは不可にする)。
しかも、これならリンクのkako対応やpath_depth操作も不要になる。
(逆に、ツールに過去ログ化を知らせるためのサインが必要になる)
転送量を問題視するなら、混雑時間帯以外とRAWMODE時のみ
透過的アクセスとする手もあるだろう。

最後に、これが最も重要だが、過去ログの形式が一定ではないという点がある。
teri,cornなどは過去ログも全て"<>"区切りだが、
mentaiから始まりpiza,saki,...等の古いログは
全て","区切りのdatが保持されている。
最も早くログ変換が始まったpizaでも5月初めで、他のサーバーはもっと遅い。
mentaiなどは大半が旧形式であると言える。
現行のparseルーチンでは、動的なデリミタ変更には対応していないので、
全て「ここ壊れています」になるだろう。
(過去に2、3度、bbs.cgiのバージョンを間違えたために
teriなのに数分間の投稿だけがsaki形式になっているdatもあるが、
これは「壊れたスレ修復」スレへ行けばよいかもしれない)
負荷との相談になるが、本気でちゃんと過去ログ読みに対応するのならば、
リンク先が無効になることより、こちらの方がずっと重要だと思うのだが。

738 :デフォルトの名無しさん :01/09/27 02:55
で、READ_KAKO,READ_TEMPの優先順位を直し、
rawmode時に対応し、temp/を廃止して一律kako/に、
等をやってみようとしたのだが、面倒になってやめた。

代わりに、AUTO_KAKOを作った。
(変更は多くないので、新しく作る方が楽)
AUTO_KAKO_MODEを数値としてdefine(SETTING_FILE可)し、
 0 = RAWモード時のみ、temp/,kako/どちらのdatも取得可能
 1 = RAWモード以外は、temp/のみ閲覧可能
 2 = RAWモード以外でも、temp/,kako/どちらも閲覧可能
とする。
過去ログに対しても全く同じようにkey=999999999の指定で
(スレスト扱いで)アクセスする。
ただし、今のところ、rawmode以外は(#if 1で)混雑時間帯外に制限してある。
READ_KAKOと排他ではないので、どちらも指定できる。

ログ形式の違いには対応していないが、
もし、READ_KAKOかAUTO_KAKO_MODE=2となることが想定されるなら、
#ifdef AUTO_LOGTYPE等として自動判別することも
そんなに難しくはないと思われる(負荷が少し大きくなる可能性あり)。

その他の変更点は、
・find_old_kakodirと同形式でfind_kakodirとfind_tempdirを作り、
 html_errorをif-elseif-else で並べた(RAWOUTも)。
・mainでファイル名を作るところがごちゃごちゃしてきたので
 create_fnameとして独立させた。
・他、細かい修正を少し。

それと、>>671の過去ログ探しが正常に動いているか確かめようと思ったら、
Ver5.23の「そんな板orスレッドないです」がでてきた。
キャッシュに残っていてNotModifiedが返ったからだが、
getFileLastmodが-1を返した(ファイルが見つからない)時は
LastModifiedを出力せず、304も返さないようにした。

739 :デフォルトの名無しさん :01/09/27 02:59
そうだ、
スレッドストッパーの判別に
「移転したよ」
もあった方がいいかも。
(1に書いてあるので有効なのは移転直後だけだし、実際には書きこみ出来るが)

740 :デフォルトの名無しさん :01/09/27 06:37
LIMIT_PMを22時にした。
"移転したよ"をストッパー判定に加えた。
AUTO_KAKO時に注意を表示するようにした。
AUTO_LOGTYPEを作った。
レス1に<>が含まれるかどうかで判定するので、
途中で一部変化しているものには対応できていない。

741 :デフォルトの名無しさん :01/09/27 11:58
</title>の前に空白入れれ

742 :デフォルトの名無しさん :01/09/27 12:04
>>741
それよりタイトル末尾の空白もCUT_TAIL_BLANKの
対象にしたほうがいいと思われ

743 :デフォルトの名無しさん :01/09/27 12:51
>>742
splitting_copy(というかressplitter_split)が各フィールド切り出すときに
統一的に末尾空白カットと空白の追加やってるようだから
すでに大丈夫と思われ

744 :名無し :01/09/28 00:06
iモードで Next Page やるとURLが見つからないみたいです。
アドレス間違えていませんか?

http://news.2ch.net/news/i/

745 :デフォルトの名無しさん :01/09/28 00:21
おの〜最新レス50を押しても最新でないんですけど、
また最新50もなんかおかしい。
バグですか?

746 :デフォルトの名無しさん :01/09/28 00:29
>745
おめーの環境が悪い。
買い替えろ

747 :デフォルトの名無しさん :01/09/28 01:21
ページ上部の1-、101-、…が相対リンクなため、
http://ebi.2ch.net/test/read.cgi/nohodame/993580528/288-/
こういうリンクで飛んだとき、1-、101-、が効きません。

748 :デフォルトの名無しさん :01/09/28 02:22
>>744
pageview.cgiはこのスレでは扱っていません。
>>745
どのスレで起きた等、詳しく説明してもらえると助かります。
>>747
こっちならうまくいきます。
http://ebi.2ch.net/test/read.cgi/nohodame/993580528/288-
最後に余分な'/'が入っている時は、
../をつけるか、無効扱いするか、どうしましょう。

749 :デフォルトの名無しさん :01/09/28 06:46
>>748
後ろに余分なものがついているときは旧形式で呼ばれたとき同様に
R2CH_HTML_BASE_DEFINEを出すとか…

750 : ◆YaKIN/eo @夜勤 ★ :01/09/28 14:44
いつも、ありがとうございます、

ところで、誰か core dump はくんですよ、read.cgi か bbs.cgi のどちらかだと
思うんですが、、、

時間あったら調べてみてください、

751 :デフォルトの名無しさん :01/09/28 16:08
>>750
 strings core | grep REQUEST
とかが可能でしたら、悪者が特定できてcore dumpの条件も判るのですが。

752 :デフォルトの名無しさん :01/09/28 16:29
bbs.cgiってPerlではなかったでしたっけ? となるとcore吐くのは
read.cgiじゃないかと思いますが gdbが使えれば
  $ gdb read.cgi core
と打ち込んで
  (gdb) bt
  (gdb) q
で出てくる結果から目星が付けられるかも知れません
coreを吐くプログラム名自体は gdbを起動した時に
  Core was generated by `hoge.cgi'.
のように表示されます

753 : ◆YaKIN/eo @夜勤 ★ :01/09/28 19:45
choco に strip してない read.cgi 入れたので、 core 吐かれたら
調べてみまーす。

754 :デフォルトの名無しさん :01/09/28 19:47
getLineMax()がちと怪しいので、一応差し替えてみたけど、どうかなあ。

755 :デフォルトの名無しさん :01/09/28 19:52
てゆーか、ミラーが死んでるから、変更点がわからないか。
do {
 ・・・
 p = (char *)memchr(p, '\n', p1-p) + 1;
} while(p != p1);
が、途中であぼーんが入るとpが死ぬ可能性があるので、
do {
 ・・・
 p = (char *)memchr(p, '\n', p1-p);
 if (p == NULL)
  break;
 ++p;
} while (p < p1);
に直した。

756 :デフォルトの名無しさん :01/09/28 20:31
datの書き込み時にどういう処理をしているのかわからないけど
もし open("hoge.dat", O_WRONLY|O_TRUNC) or fopen("hoge.dat", "w")
に相当するようなやり方でオープンして書き込んでたりすると
その書き込み中にread.cgiでBigBufferを参照すると
  ファイルの終端より後ろの領域を参照 -> SIGBUS or SIGSEGV
ということもあり得るんだな...... 例のmmap時のlock問題

757 :デフォルトの名無しさん :01/09/28 21:18
bbs.cgiに関してはそんな.dat消失の危険があることは
やらんでしょう。普通はO_APPENDを使うと思われ
流出スクリプトもそうなってるし。
ただ削除系のスクリプトはぁゃιぃかも。

758 :デフォルトの名無しさん :01/09/29 01:31
非常に簡単なテストプログラムを作ってみたのだが・・・

255個の空白と改行を1行とし、
1)まず新規にファイルを16*4行分作成し、閉じる
2)次にファイルサイズ+10バイトをPROT_READ,MAP_SHAREDでmmapする
3)マップされた領域をスキャンし、行数と最初に'\0'が現れる位置を表示する
4)次に同じファイル名で(マップしたまま)16*1行分作成し、閉じる
5)3)を繰り返す

この結果は3の時と5の時で異なり、
どちらも実際のファイルの行数(64と16)を報告し、
最初に'\0'が見つかったのは、ファイルサイズの次の位置だった。
どちらも実際のファイルサイズを超え、ページ境界をまたいでいるが、
coreは吐かなかった。
(ページ境界をまたがない時でも、
'\0'が最初に現れた位置はファイルが終わった位置だった)

もしこれ(ファイルサイズ以上の領域には'\0'が入り、
マップされている間にサイズが小さくなっても'\0'が入る)が常に当てはまるなら、
map_sizeをほんの少し多めに取り、
BigBufferをスキャンしている最中に'\0'が現れた場合のみ、
オーバーしているかをチェックすればよいことになる。

とりあえず、これが成立するを仮定して、
dat_readとressplitter_splitを修正した。

759 :デフォルトの名無しさん :01/09/29 03:32
ファイルを書きかえるプログラムとの協調ができない限り
どうやろうが危険は残る。
ターゲットOSがいつまでも同じとは限らない。
未定義部分の振る舞いなんか利用したら、後で必ず痛い目にあう。

削除ツールとかを変更できるまでは、mmapの使用はあきらめた方がいいんじゃない。

760 :デフォルトの名無しさん :01/09/29 04:08
振るまいが違ったらその時直せばいいじゃん。
納品して終りじゃないんだから。

それと「mmapの使用」と「MAP_SHAREDの使用」は等価ではないよ。

761 :デフォルトの名無しさん :01/09/29 08:35
cvs鯖落ちてる?

762 : ◆YaKIN/eo @夜勤 ★ :01/09/29 14:37
umm
choco にまだ、 core できてませんでした、
観察継続中。。。

763 :デフォルトの名無しさん :01/09/29 15:54
read.cgi の不具合報告です。
http://piza2.2ch.net/test/read.cgi/tech/1000035521/627
http://piza2.2ch.net/test/read.cgi/tech/1000035521/627/
どちらも同じ書きこみが表示されますが
下のURLだと
「■掲示板に戻る■ 全部 1- 101- 201-・・・・」
とか
>>123
などのリンク先がおかしいです。
(それともこのような指定方は想定外?)

764 :デフォルトの名無しさん :01/09/29 15:56
がいしゅつです。>>747-749
で、
・エラーにする
・R2CH_HTML_BASE_DEFINEを出す
どちらにしましょうか。

765 :デフォルトの名無しさん :01/09/29 16:55
>>764
BASE出すほうに一票

766 :デフォルトの名無しさん :01/09/29 19:15
>>732-733にあるようなdatの部分取得と、
subject.txtの上位50件取得等に対応するために、
raw=0.0時のみ、
st,to,lsを参照して要求された部分のみを返すようにすることを考え、
RAWOUT_PARTIALとして試験的に加えてみた。
(nofirstは無視したので、ls=nn時にはレス1は送信されない)

ls=nnに対応するために、送信するレス番の範囲を教える必要があり、
是非次回は続きを差分取得して欲しいから、
dat全体の中でどの部分にあたるかの、位置と範囲も返したい。
となると、部分取得時は返信ヘッダがかなり窮屈になってしまう。

実行した場合のヘッダ("/512K"以後の区切りはTAB)。
 /tech/?raw=0.0&to=50 #subject.txtの範囲指定にpathは使えない
+PARTIAL 2441/512KRange:0-2440/22735Res:1-50/478
 /tech/998845501/?raw=0.0 #今までと同じ
+OK 297551/512K
 /tech/998845501/50-99?raw=0.0
+PARTIAL 11767/512KRange:12226-23992/297551Res:50-99/883
 /tech/998845501/l50?raw=0.0
+PARTIAL 27967/512KRange:269584-297550/297551Res:834-883/883
 /tech/998845501/l20000?raw=0.0 #強引に全部送信
+PARTIAL 297551/512KRange:0-297550/297551Res:1-883/883
(本物のログとサイズが違うのは、手動でいじったからなので気にしない)

返信するステータス等を勝手に決めるのも心苦しいので、
返信コードやフォーマットなども含め、意見求む。

767 :デフォルトの名無しさん :01/09/29 19:17
cvs使えないので、ここに書いて意見を聞く
int dat_out_raw(void)
{
 const char *begin = BigLine[0];
 const char *end = BigLine[lineMax];
 char statusline[512];
 char *vp = statusline;
#ifdefRAWOUT_PARTIAL
 int first = 0, last = 0;
 if (raw_lastnum == 0 && raw_lastsize == 0
  && (nn_st || nn_to || nn_ls > 1)) {
  /* nn_xxはnofirstの関係等で変化しているかもしれないので再算出 */
  int st = atoi(zz_st), to = atoi(zz_to), ls = atoi(zz_ls);

  first = 1, last = lineMax;
  if (ls == 1)/* for Ver5.22 bug */
   ls = 0;
  if (ls)
   st = lineMax - ls + 1;
  if (0 < st && st <= lineMax)
   first = st;
  if (0 < to && to <= lineMax)
   last = to;
  if (first > last)
   last = first;

  begin = BigLine[first-1];
  end = BigLine[last];
  vp += sprintf(vp, "+PARTIAL");
 } else
#endif
 /* ・・・ */
 if (・・・) {
  ・・・
 } else {
  ・・・
 }
 vp += sprintf(vp, " %d/%dK", end - begin, MAX_FILESIZE / 1024);
#ifdefRAWOUT_PARTIAL
 if (first && last) {
  vp += sprintf(vp, "\t""Range:%u-%u/%u",
   begin - BigLine[0], end - BigLine[0] - 1, BigLine[lineMax] - BigLine[0]);
  vp += sprintf(vp, "\t""Res:%u-%u/%u", first, last, lineMax);
 }
#endif

768 :デフォルトの名無しさん :01/09/29 19:17
続き
#ifdefAUTO_KAKO
 {
  static char *messages[] = {
   "",
   "\t""Status:Stopped",
   "\t""Location:temp/",
   "\t""Location:kako/",
   /* 正確な位置を知らせる必要はないはず */
  };
  int where = zz_dat_where;
  if (where || isthreadstopped())
   where++;
  vp += sprintf(vp, "%s", messages[where]);
 }
#endif
 pPrintf(pStdout, "%s\n", statusline);
 ・・・
}

769 :デフォルトの名無しさん :01/09/29 19:45
subject.txtのraw=0.0時の出力内容は、意味的には1が最新だし、
途中からの受信はそれまでの取得済み内容の続きにできないので
st, toは無視して、lsで先頭からの個数を指定するほうが
より良いような気もする。

770 :デフォルトの名無しさん :01/09/30 00:23
かちゅ〜しゃのgzip対応化DLLを作っている者です。
現在のrawモードの仕様だと最終レス番号を指定しなくては
ならないので、これをログから取得しているのですが、
ディスク上のログがすぐには更新されないとか、
ログ保存をオフにしたりレス取得上限を設定したり
されると対応できないとか、いろいろ大変です。
http://piza2.2ch.net/test/read.cgi/tech/1000035521/?raw=.12345
のように、レス番号指定を省略しても(指定位置が
ちょうど行頭なら)差分だけを返すようにできないでしょうか?

771 : ◆YaKIN/eo @夜勤 ★ :01/09/30 02:57
以下のサーバに mod_gzip が導入それました。

mentai , saki/corn , cheese/cocoa , teri/ton , kaba , bbspink2
www/salami , salad , yasai , natto , ebi/curry

そこで yasai に read.cgi を /*#define GZIP*/ のようにコメントアウトして
コンパイルしたものを上げました。
本当はどうすればいいのかな? 教えてください、おねがいします。

772 :デフォルトの名無しさん :01/09/30 04:21
今、永らく読んでなかったかちゅスレ(18-19)を読んでます。
伸びが急激なので、まだ19の途中ですが。
proxyではなく、DLL対応とは結構驚きました。

で、できるだけ(他の人の同意があれば)対応する方向にしたいのですが、
現行のかちゅ〜しゃをサーバー側から見ると、2つ程欠点があります。
1つ目は、If-Modified-Sinceを付加していないこと
2つ目は、常に1バイト以上の送信をリクエストすること
です。
どちらも本質は同じで、更新がなくてもファイルI/Oの負荷が発生するため、
必要以上にサーバーに負担をかけることになっています。
多分、かちゅ〜しゃのidxに保存されているのは
サーバー側のLastModifiedではなく、ローカル側のGET日時だと思うので
難しいとは思いますが、可能ならば、If-Modified-Sinceをお願いしたいです。

実際の対応ですが、
まだwsockspyのソースもろくに読んでいないので
外れたことをいってるかもしれませんが、
その形式だと、最終の'\n'部をGETしないため、
リクエストのRangeが範囲を超える場合が頻発すると思います。
その場合、
・Rangeの範囲がファイルサイズジャストの次からだった場合
→304 NotModifiedを返す
としたいと思いますが、よいでしょうか?
また、
・Rangeの範囲が大きく超えた場合、及び、指定位置が行頭ではなかった場合
はどうしましょう?
かちゅ〜しゃでは、
あぼーん等でRangeが範囲を超えていて全体が返された場合でも
(ローカルあぽーん等の結果が無効となるため)
それを利用してログを再構築する事はせず、
常に「ログが詰まった」を表示しているように思います。
ですので、この場合はエラーが起きたことだけを知らせ、
全体は返さないようにしたいと考えていますが、
それでよいでしょうか?

773 :デフォルトの名無しさん :01/09/30 04:21
あと、「過去ログが取得できない」問題は、
read.cgi側でAUTO_KAKOをONにすれば即対応可能です。
夜勤さんにお願いするしかないですが。
こうなった場合、最初のGETで取得できなければ、
../kako/や../dat2/をGETするのは完全に無駄なので
DLL側で(302を返すよう)対処してもらえればと思います。
(-ERRの戻りが、「../kako/...で発見」の場合は非対応)

もう1つ、他のツールの作者さんも読んでいると思うので。
この形式での対応は、
Accept-Encoding: gzip
かつ、
User-Agent: Katjusha
の場合だけにしたいと思います。
これは、同様のリクエストは(レス番号さえわかれば)
RAWOUT_PARTIALで対応可能で、
そこで返されるRangeを見ればあぼーん等の検出も可能であり、
ツールの(ソースに触れる)作者から見れば
あまり必要のない機能だと思うからです。
かちゅ〜しゃユーザーののgzip移行を促すためにも
あえて厳しくしたいと思います。

774 :デフォルトの名無しさん :01/09/30 04:25
あ、以上は>>770でした。

mod_gzip導入については、
特に何もしなくてもいいと思います。
(全鯖導入されたら、index.htm/index.htmlチェックが不要になるので消しますか)
GZIPは、ZLIBが定義されていると再defineされちゃいますし。

775 :デフォルトの名無しさん :01/09/30 08:07
cvs復活してるね

776 :デフォルトの名無しさん :01/09/30 08:50
http://www.gedoh.org/aki/2ch/current/bbs/
がInternal Server Errorになるよー

777 :770 ◆DLL/lGHE :01/09/30 09:10
>>772-773
「Range:」ヘッダは削除して、?raw=nn.xxxxに変換しています。

>・Rangeの範囲がファイルサイズジャストの次からだった場合
>→304 NotModifiedを返す
>としたいと思いますが、よいでしょうか?

よって「+OK 12345/512K」みたいな1行だけが返ってくる
はずなのでとくに考慮は不要です。

内部的に、ファイルサイズジャストでも実際にファイルを読み込
んで処理しているとしたら、その内部処理だけを修正してインター
フェースは変えない(上記のヘッダ行を生成する)ようにしたほうが
いいのではないでしょうか。

>・Rangeの範囲が大きく超えた場合、及び、指定位置が行頭ではなかった場合
>はどうしましょう?

おっしゃる通り、エラーの通知のみでいいと思います。

>あと、「過去ログが取得できない」問題は、
>read.cgi側でAUTO_KAKOをONにすれば即対応可能です。

過去ログに関しては.datをmod_gzipの圧縮対象に指定するという
手もありますね(過去ログの差分取得はあまり行わないでしょう
から)。

>DLL側で(302を返すよう)対処してもらえればと思います。

今でも、「過去ログ倉庫で発見」以外のエラーのときは
無駄なリクエストが飛ばないように対処済みです。
ちなみに、BIG-serverではNot Foundだったとき404を返す
代わりに news.kakiko.com/mentai/ へ飛ばす(302を返す)
ようになっているので、302ではだめです。

778 :770 ◆DLL/lGHE :01/09/30 09:13
Last-Modifiedについては、ファイルサイズジャストのとき
中身を読まないように修正すれば結局stat一回だけなので
対応不要だと思っているのですがどうでしょうか?

779 :デフォルトの名無しさん :01/09/30 09:19
AUTO_KAKO関係、AUTO_LOGTYPE関係とその周辺を少し変えた。
rawmode時はget_title()等を呼ばないようにした。
subject.txt取得時と!busytime時はMAP_PRIVATEにした。
RAWOUT_PARTIALで、subject.txt取得時のみ、
lsがあってtoがなかったら、lsをto扱いするようにした。
Katjusha_DLL_REPLYを作った。

read.cにデバッグコードが残ってたらごめん。

>>778
LastModifiedの判定の他にサイズ判定をいれたので、要らなくなったです。

780 :デフォルトの名無しさん :01/09/30 09:26
>「Range:」ヘッダは削除して、?raw=nn.xxxxに変換しています。
あ、そういう意味です。

>よって「+OK 12345/512K」みたいな1行だけが返ってくる
>はずなのでとくに考慮は不要です。

これは、read.cgi側の都合です。
+OKを返すときは、通常、HTTPヘッダを全て出力した後、
さらにdatを読みこんで(行数を数える等もして)からなので、
サイズだけでNotModifiedが返せた方が楽だからです。
サイズだけで判定して+OKを返しても大差ないといえばその通りなのですが。

>ちなみに、BIG-serverではNot Foundだったとき404を返す
>代わりに news.kakiko.com/mentai/ へ飛ばす(302を返す)
>ようになっているので、302ではだめです。
「302を返す」は、そのつもり(404の代わり)で書きました。
かちゅ〜しゃは302に反応すると思われるので、
見つからない時にはDLLで細工してかちゅ〜しゃに302を返すという意味です。

っていうか、cvs修正した直後に>>777(おめでとう)を読んだので、
サイズジャストは+OKではなく、NotModifiedのままです。
直しましょうか?

781 :デフォルトの名無しさん :01/09/30 09:30
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342

782 :デフォルトの名無しさん :01/09/30 09:33
>+OKを返すときは、通常、HTTPヘッダを全て出力した後、
>さらにdatを読みこんで(行数を数える等もして)からなので、
>サイズだけでNotModifiedが返せた方が楽だからです。

なるほど。「+OK」を返してもらえると私(とかほかのツール
作者)が楽なので結局どちらが楽できるかの問題ですね。

>サイズジャストは+OKではなく、NotModifiedのままです。
>直しましょうか?

面倒でなければお願いします(^^;。

783 : ◆DLL/lGHE :01/09/30 09:36
782も私です。

よく考えたらレス数を求めるには中身を読まなくてはならないから
ほかのツールは関係ないですね。

784 :デフォルトの名無しさん :01/09/30 09:54
仕様書き忘れてました。
今(304を返す仕様)のところ、

・ファイルサイズと一致
304 Not Modified
Content-Type: text/plain
(ヘッダのみ)
・あぼーんされたっぽい(要求Rangeが大きすぎ)
-ERR どこかであぼーんがあったみたいです。
(非圧縮・この時はLast-ModifiedやContent-Encodingを出力しない)
・あぼーんされたっぽい(要求Rangeが大きすぎ)
-ERR どこかであぼーんがあったみたいです。
(ヘッダにLast-ModifiedとContent-Encodingが含まれる)
・続きあり
+OK 27967/512K
・・・

wsockspyのソースを見て問題なさそうだったので、
サイズだけをみてあぼーんが判断できる場合は
非圧縮で返すようにしています。

あと、304を返す代わりに
+OK 0/512K
にする方向にしますね。

785 : ◆DLL/lGHE :01/09/30 09:57
>・あぼーんされたっぽい(要求Rangeが大きすぎ)
2つありますけど下のは

・あぼーんされたっぽい(行頭ではない)
ですね。

786 :784 :01/09/30 10:02
>>785
ごめんなさい。その通りです。

ところで、他のツールの場合は
必ずIf-Modified-Sinceをつけてくると思いこんでいたので、
「raw=x.xでファイルサイズジャストの場合」というのは
あまり想定していなかったんですが、
もしかしたら、
raw=x.xのリクエスト全てに対して、
「ファイルサイズジャストなら+OKの行のみを返す」
ことを考えた方がいいかもしれませんね。
その方向で考えます。

787 :デフォルトの名無しさん :01/09/30 10:12
仕様が固まったらread2ch.hとconfig.txtの更新もよろしくー

788 :デフォルトの名無しさん :01/09/30 10:14
>>787
ChangeLogもね(o^-')b

789 :784 :01/09/30 10:35
>>786の変更を加えた。

うーん、でもよく考えたら、If-Modified-Sinceには
「実況禁止」効果を見こんでいた部分があるので、
できれば何か対策が欲しいところでもある。

>>787-788
これからやりまーす。

790 :デフォルトの名無しさん :01/09/30 10:45
>>786
OKのみの行を返すときでもLast-Modifiedはあったほうがいいような。
サイズは一致していても変更があったかもしれないし(まれだろうけど)

791 :784 :01/09/30 11:29
read2ch.h,config.txt,ChangeLogを更新しました。

Last-Modifiedはどうしましょ?
サイズを見てOKのみを返す場合は、
既にIf-Modified-Sinceのチェックをくぐってしまった時なので、
そういうUAにLastModifiedを返す必要があるかとか、考えたんですが。
まあ、出す分には全然かまわない気もします。
ただ、「偶然の一致」を減らすなら、レス数も数えた方がいいでしょうし。

あと、この場合にはContent-Lengthも返さないので
それも問題ありかもしれません。

792 :784 :01/09/30 11:46
サイズを見て+OKのみを返す場合に、条件として
「If-Modified-Sinceがなかった場合」を加えてみた。

793 :デフォルトの名無しさん :01/09/30 14:00
おお、mod_gzipはいったんだ。ご苦労様>>夜勤さん

Trying 64.71.134.194...
Connected to piza2.2ch.net.
Escape character is '^]'.
HEAD /tech/index.html HTTP/1.1
HOST: piza2.2ch.net
Accept-encoding: gzip, inflate

HTTP/1.1 200 OK
Date: Sun, 30 Sep 2001 04:55:31 GMT
Server: Apache/1.3.6 (Unix) PHP/4.0.3pl1 mod_gzip/1.3.19.1a mod_ssl/2.3.6 OpenSS
L/0.9.3a
Content-Type: text/html

って 771みると piza2には前から入ってた?

794 :デフォルトの名無しさん :01/09/30 15:12
対応したread.cgiが導入されるまでの間、
かちゅーしゃでの巡回は
今まで以上に無駄な負担を鯖に強いることになるわけか。
巡回が重くなったって言われるのもわかる気がする。
mod_gzipで重くなったってのもあるだろうけど。

795 :デフォルトの名無しさん :01/09/30 16:41
Katjusha_DLL_REPLY時には、
getLineMaxで全体を走査する必要がない事に気付いたので、変えた。

そうすると、この形式は、他の?raw=x.xのリクエストに比較して、
(mmapが有効に使える点も含め)負荷的に有意ということになる。
ならば、UserAgentチェックも外して、
他のツールにも積極的に利用してもらうことも考えた方がいいかな?
UserAgentチェックは、かちゅ〜しゃ利用者の(変更しての)
非rawモードでのread.cgi呼出を減らせるかも、と考えたからなんだけど。

796 :デフォルトの名無しさん :01/09/30 18:39
>>747-749,>>763-765
PATH形式での呼出時、解析された以降の文字列に'/'が含まれるとき、
BASE_DEFINEを出力するようにした。

797 :デフォルトの名無しさん :01/10/01 04:17
>>795
UAチェック外すほうに一票。

798 :デフォルトの名無しさん :01/10/01 10:29
rawモードでファイルサイズジャストの時にも
Last-ModifiedとContent-Lengthを出すようにした。
raw=.nnn形式のUAチェックを外した。

というのをやったんだが、cvs鯖落ちてるっぽい。

799 :デフォルトの名無しさん :01/10/01 10:43
今はcvs動いてるみたい

800 :デフォルトの名無しさん :01/10/01 12:15
>>799
ありがと。
>>798をcommitした。

801 :名無しさんの声 :01/10/01 16:14
iモード時の要望です。
批判要望板のスクリプト関連要望統合スレッドにも
書き込んだのですが

iモードでスレ巡回するときは
決まったスレを見ることが多いので
1-10よりも最新-5レス前 とか5レス前-10レス前とか
今見てるとこから数レス前とかの方が便利です。

現在iモードから見る際
ログが流れると1-10を開いてブックマークしてから
編集して見たいレス番号に書き換えて移動って
手順で見ているので何かと不便で博打性も強いです。

手間がかかるかも知れませんが検討をお願いしたいと思います。

802 :デフォルトの名無しさん :01/10/01 19:53
>>801
最新10レスというのがなかったか?

803 :デフォルトの名無しさん :01/10/01 19:54
「大きすぎます」対策として、ファイルサイズが
MAX_FILESIZE - 4255バイトを超えたら
フォームを消すようにできませんか?

804 :デフォルトの名無しさん :01/10/01 19:58
CGI自身にgzip圧縮の機能がなくても、その先のmod_gzip
が圧縮してくれるかもしれないので、BadAccess中での
gzip_flagの判定とかNN4_LM_WORKAROUNDの処理とか
Katjusha_DLL_REPLYの判定とかはしたいのですが、
これらをGZIPのconditionから外に出せませんか?

805 :デフォルトの名無しさん :01/10/01 21:49
>>804
mod_gzipに圧縮をまかせたら、NN4_LM_WORKAROUNDは役にたたないよ。

806 :デフォルトの名無しさん :01/10/02 00:20
bbs.cgiがパス対応になったので、USE_PATHとALWAYS_PATHは
オン固定にしましょう。

807 :デフォルトの名無しさん :01/10/02 00:44
>>805
mod_gzipが勝手に付けちゃうの?
そうだとしても後2つのこともあるし。

808 :デフォルトの名無しさん :01/10/02 05:37
むー、なんか俺には意味が完全には把握できない話が続いている気がする。

>>801の件は、>>802の言うように
「最新10」「前10」「次10」があった気がするのだが。
もう一回確かめて、なければ作る。
上部に欲しいということかな?
もしかしたら、呼出形式によっては表示されないかもしれないので、
・どういう形式のリンクだと不足があるのか(実例を出してもらえるとうれしい)
・その時に、現状のほかにどんなリンク先が欲しいか
を書いてもらえると助かる。

>>803の件は4255というのが「1レスの最大バイト数」なのかもしれないが、
これは>>nnのリンクや改行の数によって左右されないのかな?
よくわからないので、
#define WRITESTOP_FILESIZE 5 として、
MAX_FILESIZE - WRITESTOP_FILESIZE*1024 を超えたら、
スレッドストップ扱いにしてみた。

>>806
USE_PATHとALWAYS_PATHはON固定で良さそうなので、そうした。
RAWOUTも外せない機能ではあるが、
こちらは、「RAWモード専用CGI」の可能性があるので、残しておく。

809 :デフォルトの名無しさん :01/10/02 05:38
>>804の意図が一番わからないのだが、
>CGI自身にgzip圧縮の機能がなくても、その先のmod_gzip
>が圧縮してくれるかもしれないので、
これは、mod_gzipがcgi出力も圧縮するという意味だろうけど、
>BadAccess中でのgzip_flagの判定とか
>NN4_LM_WORKAROUNDの処理とか
>Katjusha_DLL_REPLYの判定とかはしたいのですが、
>これらをGZIPのconditionから外に出せませんか?
「これら」というのが何を指しているのかが不明なので、よく理解できない。
「Accept-Encodingを見てgzip_flagを設定すること」を言っているのか、
「rawmode時等に圧縮非対応のリクエストは受け付けない」を言っているのか、
「NN4リクエスト時にContent-Lengthを出力しない」を言っているのか、
「rawmode以外はKatjushaのリクエストを受け付けない」を言っているのか。

出力の圧縮を完全にmod_gzipに任せることになった場合、
#define GZIP/ZLIBを外す事になり、
そのことにより、いくつかのリクエストがBadAccessで弾けなくなり、
特にrawmode関係のリクエストが受け付けられてしまうのがまずいということかな?
それなら、その通りだとも思うけど。
ただ、出力の圧縮を全てmod_gzipに任せる可能性はあるかな?

というか、既に、
http://piza2.2ch.net/test/check.cgiの出力なんかは圧縮されて返ってくるから、
どちらかというと、
・CHECK_MOD_GZIPで、mod_gzipが導入されていれば、圧縮しないで出力する
・BadAccessで、圧縮を受け付けないrawモードのリクエストは弾く
ぐらいでもいいかもしれない。
負荷的にも、mod_gzipに任せた方がいいかもしれないし。
ただ、NN4時にもContent-Lengthを付けてしまう(おそらく)のが欠点か。

810 :801 :01/10/02 05:50
>802>808
確認しました。付いておりました。
多謝です。お騒がせして申し訳ありません。

811 :デフォルトの名無しさん :01/10/02 06:45
>>809
mod_gzipが入ってるならGZIP/ZLIBとも外したほうが
オブジェクトサイズの節約になるのでは。
とくにZLIBはスタティックリンクされてますし。
で、現状ではGZIP/ZLIBを外してしまうと、たとえば
rawモードの取得をgzip対応クライアント以外に認め
ない機能も消えてしまうと言いたかったわけです。

812 :デフォルトの名無しさん :01/10/02 07:10
了解。

ZLIB/GZIPはOFFにする方向で、
なおかつrawモード時のAccept-Encodingチェックは行うにする、と。
かちゅチェックは、rawモードに含まれるのでそのままでもよさそう。
NN問題はとりあえずあきらめて、
圧縮をmod_gzipに任せ、cgiサイズ(と負荷)が小さくなるようにする。

この方向でよい?

813 :デフォルトの名無しさん :01/10/02 07:12
read.cgiが生成するURLは常にパス仕様になりましたから、
create_link()の旧形式を生成してる部分はバッサリ削除
できます。

814 :811 :01/10/02 07:15
>>812
かちゅチェックは
main()の
#ifdefined(GZIP) && defined(RAWOUT) && defined(Katjusha_DLL_REPLY)

#ifdefined(RAWOUT) && defined(Katjusha_DLL_REPLY)
にしてくださいと言いたかったのでした。
あとはよいと思われ

815 :デフォルトの名無しさん :01/10/02 08:17
>>813
#ifndef ALWAYS_PATHに相当する部分なので消してもよいかと思ったが、
一応#ifdef CREATE_OLD_LINKで囲むだけにした。
>>814
read2ch.hは変えなかったが、
GZIP/ZLIBがなくてもAccept-Encodingをチェックするようにした。

816 :デフォルトの名無しさん :01/10/02 12:57
たまたまrawモードをブラウザで叩いてみたんですけど、
>>[レス番号] にアンカー入ってるんですけど…こういう仕様ですか?

817 :デフォルトの名無しさん :01/10/02 13:05
>>816
bbs.cgiが.datに書き込んでるので仕様です。
read.cgiは仕方ないので指す先を捨ててURLを再生成してます。

818 :デフォルトの名無しさん :01/10/02 13:16
>>817
解かりました。有難う御座います。

819 :林檎おいしいよ。 :01/10/02 16:30
がいしゅつだったらスマソ。。
ニュー速板で、"最新50"の時、下の「掲示板に戻る」をクリックしたら、
http://news.2ch.net/news/index.htmに行っちゃって、
ブックマーク変更してねっていわれちゃったんですけど。。
私はとっくに変更済みなんですけど、
夜勤さんに念のためここで報告するようにいわれたので。。よろしくです。

820 :デフォルトの名無しさん :01/10/02 19:43
どうやらmod_gzipがまだ入っていない板でもindex.htmが
廃止されたみたいなので判定のロジックはばっさり
捨て去ったほうがよさそう

821 : ◆YaKIN/eo @夜勤 ★ :01/10/02 21:00
お世話になってま〜す。
負荷がばかにならないくらいあがっています。
なにやら かちゅーしゃとかが新しくなったとか。。。(詳しく知りません)

で提案なんですが、ご検討していただけないでしょうか?
-------------------------------------------------------------
大きな流れとしては、各ツールの要求に答えていくことなんだけど、、、
うーん 転送量の次は負荷が、

dat を細切れにして、さらに圧縮をかけて転送量を削る方向に
向かっているから、これをやめるのが吉か?

ルールが必要か?
1.dat 読みのときは、一気に全部読む。
2.read.cgi はあらかじめ作ってある xxxxxxxxxxxx.dat.gz を返す。

まずは、プログラム板で聞いてこよう。

822 : ◆DLL/lGHE :01/10/02 21:04
差分はdat経由で読むようにしましょうか?
とりあえず現在開発中のバージョン入れてKatjusha_DLL_REPLY
が使えるようになると負荷が多少は減ると思います。

823 :デフォルトの名無しさん :01/10/02 21:06
夜勤さん、かちゅ"〜"しゃです。。。
それとかちゅ用のwsock32.dll作ってる人に聞くと仕様わかるっすよ。

824 :823 :01/10/02 21:07
( ̄□ ̄;)!! のんびりし過ぎた!!

825 :デフォルトの名無しさん :01/10/02 21:21
プロセス起動数の増加による負荷を下げるなら、
rawモードをさらに拡張して複数dat同時転送とかできませんかね。

826 :デフォルトの名無しさん :01/10/02 21:26
read.cgiをApacheモジュールにしちゃえば軽くなるんだろうけど
mod_gzipの導入でもいろいろ交渉したりしなきゃならなかったみたいだから
大変なのかな......CGIプロセス起動しない分軽くなるのは確実だけど

827 :デフォルトの名無しさん :01/10/02 21:27
みんな速くなってますます巡回しまくっちゃったりして…

828 :デフォルトの名無しさん :01/10/02 21:28
read.cgiが自分でgzipを使うかを動的に選択できるのなら、
raw差分転送である程度以下のサイズのものは圧縮しないようにするとか。

829 :デフォルトの名無しさん :01/10/02 21:32
それはmod_gzipがすでにやってたりして…
そういう意味でもmod_gzip任せにしたほうがいいのかも。

325KB
新着レスの表示

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30