monazilla Part 5

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

1 ： ◆gfD86vH6Zo ：03/07/04 23:32: ２ちゃんねる専用のブラウザを作っちゃおう
というプロジェクトです。
［前スレ1より］

Part 1　http://pc.2ch.net/test/read.cgi/tech/981726544/
Part 2　http://pc.2ch.net/test/read.cgi/tech/1005282763/
Part 3　http://pc3.2ch.net/test/read.cgi/tech/1012544484/
Part 4　http://pc2.2ch.net/test/read.cgi/tech/1042432238/

monazilla.org (w
http://www.monazilla.org/
893 ：はらぐろ ：2008/07/25(金) 00:02:36: 変更ありがとうございました。
894 ：デフォルトの名無しさん ：2008/09/13(土) 18:35:27: 保守ですまん
895 ：名無しさんだよもん ：2008/09/15(月) 23:50:40: プログラマー諸氏がんがれ！
896 ：デフォルトの名無しさん ：2008/09/16(火) 22:00:17: イヤなんか今さら開発しても出尽くしてるし・・・みたいな・・・
897 ：デフォルトの名無しさん ：2008/09/16(火) 23:46:16: rep2がもっとクライアントサイドによらんかなってのはある
スレ一覧のソートぐらいならJavascriptでできるんじゃないか、とか
898 ：デフォルトの名無しさん ：2008/09/17(水) 12:24:32: さすが kage だ何ともないぜ… Cookies.txt の hana=mogera 系エントリが無限に増えそうで
怖いけど
899 ：デフォルトの名無しさん ：2008/09/29(月) 23:37:21: DATの差分取得を試みているんですが、

If-Modified-Since: リモートDATの最終更新時刻(値は応答ヘッダのLast-Modifiedを調べる)
Range: bytes=ローカルDATのファイルサイズ-

の２つを要求ヘッダに入れることは必須ですか？
それともRangeだけでも差分取得は出来ますか？

膨大な数のdatファイルごとにIf-Modified-Since値を記憶しておくのは管理が面倒です。
ローカルのDATファイルのサイズは簡単に調べられますのでRangeだけで差分取得
ができるのならプログラムはぐっと簡単になります。

http://age.s22.xrea.com/talk2ch/
900 ：デフォルトの名無しさん ：2008/09/30(火) 00:19:40: あぼーんで減ったバイトと新たな書き込みで増えたバイトが
たまたま同じだった場合、rangeだけでどうする？
901 ：デフォルトの名無しさん ：2008/09/30(火) 00:28:42: ローカルのdatファイルの最終更新日時を使うのじゃだめなの？
902 ：899 ：2008/09/30(火) 01:21:43: >>900
事前にsubject.txtをDLして各スレのレス数を解析しておこうと思っています。
これなら新たな書き込みがされればレス数が増えてるので、たまたまバイト数
が同じだった場合でもあぼーんを検知でき（実際何もDLされてこないわけですから）
ると思います。

>>901
ローカル側のファイル更新時刻をif-Modified-Since型に変換できるなら
それもありのような気がします。
903 ：899 ：2008/09/30(火) 01:28:28: ちょこちょこっとプログラムを組んでみたんですが、

if-Modified-Since

を指定しないと差分取得は出来ないようですね。
いくら Range でローカル側のファイルサイズを申告しても
1からdatを再取得してしまうようです。

差分取得するならローカル側のファイルの更新時刻をどうにかして
調べて if-Modified-Since に収納してやらないとならないようです(´･ω･｀)
904 ：デフォルトの名無しさん ：2008/09/30(火) 01:48:26: Last-Modifiedだけでなく、ETagも見た方がいい
 >>424とか参照
905 ：899 ：2008/09/30(火) 02:33:59: >>904
たとえばC#でLast-Modifiedを保存するには

HttpWebRequest.LastModified

でリモートファイルの更新時刻を取得することができ、
またデータのフェチの際は

HttpWebRequest.IfModifiedSince

に更新時刻を出力すればサーバーとやりとりできました。

ETagに関してサーバから取得、出力するにはどうしたらいいでしょうか？
出力に関しては

HttpWebRequest.IfNoneMatch

でETagをサーバーに送信できるようですが、ETagの取得に関しては
どう操作すればいいか分かりません(´･ω･｀)
906 ：デフォルトの名無しさん ：2008/09/30(火) 05:08:15: ここで特定のフレームワークのこと聞かれてもな
まあ、普通に考えれば任意のヘッダを送受信する手段くらいあるはず
探せ
907 ：デフォルトの名無しさん ：2008/09/30(火) 12:31:27: ETagにしろ更新日時にしろ応答ヘッダで返ってくるんだが
まずHTTPの資料を読むことを薦める

あと、>>902の方法だと透明あぼーんしか検知できなくないか？
subject.txtを毎回取得しにいく仕様もどうかと思うぞ
908 ：デフォルトの名無しさん ：2008/09/30(火) 12:53:11: >膨大な数のdatファイルごとにIf-Modified-Since値を記憶しておくのは管理が面倒です。
そもそもこんなことを言ってる時点で（以下略

他の専ブラ参考にすれば？
datと同名のidx作って管理するとか、データベース使うとか、datの扱いの基本中の基本でしょ。
909 ：デフォルトの名無しさん ：2008/09/30(火) 13:01:47: たまにだけど、subject.txtのレス数と実際のレス数が違うことがあるから100%信用すると痛い目に遭いそう

秒単位の更新チェックは知らなかった・・・ツール更新しなきゃ
910 ：899 ：2008/09/30(火) 15:08:16: ETagはサーバーが返してくる値をローカルに保存しておかないといけないですか？
ローカルに保存したdatファイルからETag用の値を計算できればわざわざ
ローカルにETag値を保存しておく必要は無くなると思うのですが。
911 ：デフォルトの名無しさん ：2008/09/30(火) 15:35:24: じゃあそうすれば？
912 ：デフォルトの名無しさん ：2008/09/30(火) 19:49:15: ローカルに ETag を算出…？どうやって？まさか「ETag 計算方法」とかでググって
出てくるものを実装して「たまたまそのとき一致したらからおｋ」とか思ってないよな？
913 ：デフォルトの名無しさん ：2008/09/30(火) 20:55:40: 弱いETagならローカルで算出やつでも通用するんじゃない？
強いETagはまず不可能だろうけど
914 ：899 ：2008/09/30(火) 21:45:35: 話は変わりますが、サーバーにDATを要求し、返ってきたヘッダーに書かれた情報を見ようと

GetResponseHeader("Content-Range")

という命令を書いてみたのですがなぜか何も取得できませんでした。

GetResponseHeader("Content-Length")
GetResponseHeader("Content-Type")

はきちんと値が返ってきました。

2chの鯖には変数"Content-Range"を返さないものがあるということでしょうか？
915 ：デフォルトの名無しさん ：2008/09/30(火) 21:49:47: 送るヘッダが間違ってるだけだろ
916 ：デフォルトの名無しさん ：2008/09/30(火) 22:05:37: 誰か多段ポップアップの方法をVBでお願いします。
あれはスキンとかに対応してjavascriptで実装したほうが簡単なのでしょうか…
917 ：899 ：2008/09/30(火) 22:47:34: もう一つヘッダがらみの質問です

2chでは転送量を抑えるためGZipで圧縮をかけたデータのやりとりを推奨
しているようです。そこで以下のように（言語はC#です）GZipフラグをヘッダ
に付けてリクエストを出すようにしています。

webRequest.AutomaticDecompression = DecompressionMethods.GZip;

ただこの方法だと差分取得で問題が発生してしまいました。

webRequest.AddRange( fileSize );

の fileSize の部分にローカルにDLしたDATファイル(GZip圧縮は解除され
平文のテキストファイルです）のファイルサイズを調べて指定したのですが、
どうやらGZipフラグを付けると AddRange で指定すべきファイルサイズは
GZipで圧縮したときの容量ではないといけないようなんです。

ローカルのDATファイルのファイルサイズを指定すると416:RequestedRangeNotSatisfiable
が返されてそれ以降DATを取得できなくなってしまいます。

GZipで差分データをやりとりするときは、GZip圧縮をかけた状態で受け取った
DATのサイズを計測し、それを累積加算しながら AddRange でリクエストしない
とデータは取得できないのでしょうか？DATファイルひとつごとにGZipで受け取った
ときのサイズを累積加算してローカル側に記憶しておく必要があるうえに、
万が一その値を失った場合は最初からDATを取得しなければならない等
不便が予想されるわけですがみなさんはどうやって対処されていますか？
918 ：デフォルトの名無しさん ：2008/09/30(火) 23:13:59: 今はgzipなんて推奨してません。
919 ：デフォルトの名無しさん ：2008/09/30(火) 23:16:33: というのはウソです。
920 ：デフォルトの名無しさん ：2008/09/30(火) 23:23:03: 関連するAPIをぜんぶ実装して
モジュールとして公開してくれてるひとっていますか？
921 ：デフォルトの名無しさん ：2008/09/30(火) 23:23:58: >>917
twintailはどうなってるのか読んでみた？
C#のソースが公開されてるから読んでみたら？
http://www.geocities.co.jp/SiliconValley/5459/
922 ：899 ：2008/10/01(水) 01:15:16: >>917に自己補足です。
GZip圧縮を有効にしたとき、鯖によってうまくいったりいかなかったりするようです。

実況鯖はGZip圧縮をONにしてもうまく差分取得できました。
一方でN速＋といった通常鯖はGZip圧縮をONにすると
416:RequestedRangeNotSatisfiable
エラーが返されてしまうようです。

２ちゃんはGZip圧縮は非推奨ってことなんでしょうか(´･ω･｀)？

>>921
ありがとうございます。
時間ができたときにソースコードを読ませてもらいます。
923 ：デフォルトの名無しさん ：2008/10/01(水) 01:19:03: 転送量が問題だったのは過去の事
924 ：899 ：2008/10/01(水) 01:25:33: >>923
> 転送量が問題だったのは過去の事

そ、そうなんですか（；´∀｀）

それでは多くの２ちゃんブラウザではGZip圧縮をかけずに転送してるんでしょうか？
925 ：デフォルトの名無しさん ：2008/10/01(水) 01:39:01: 今はサーバーリソースの方が問題だからそもそもgzipの圧縮をやらない。
926 ：899 ：2008/10/01(水) 02:02:23: >>921
> http://www.geocities.co.jp/SiliconValley/5459/

で紹介されたTwinTailブラウザのソースをざっとですが見てみました。

ソースコードの中に
「datファイルがgzip圧縮されていればtrue、そうでなければfalseを指定する」
と記述されたパートがありました。もしかしたら鯖ごとにdatがGZip圧縮されて
いたりされていなかったりするということでしょうか？

>>922の例で言えば実況鯖はGZip圧縮がONで、それ以外の一般鯖はGZip圧縮
がOFFだったため、違いが生じたのでしょうか？

だとしたら何らかの方法で鯖ごとにGZip圧縮されてるかされてないかを識別し、
それに従ってdatをフェチする際にGZip圧縮フラグをONにするかOFFにするか
自動選択させればどの鯖にも対応できるようになるかもしれません。

あるいはGZip圧縮は無視して全鯖非圧縮でdatを取得するようにしてしまっても
いいかもしれませんね(´･ω･｀)
927 ：デフォルトの名無しさん ：2008/10/01(水) 03:01:08: GZIP要求を出して圧縮されて返ってくれば解凍、datで返ってくればそのまま
どちらの形式で返ってきたかは応答ヘッダを見ればいい

GZIP圧縮すべきかどうかは >>248-249
928 ：デフォルトの名無しさん ：2008/10/01(水) 12:59:26: HTTPプロトコルを理解するためにRFC2616を読んだり
Wiresharkとかで既存ブラウザがどういう通信しているか見ればいいのに
929 ：899 ：2008/10/01(水) 13:00:32: >>927
もう一度調べてみたんですが、要求ヘッダに

req.AutomaticDecompression = DecompressionMethods.GZip;

とGZipをリクエストしておけばほとんどの鯖はGZipで圧縮されたデータを
送信してくれるようです。

では問題は何かと言いますと、初回以降の差分要求をするときにヘッダー
に付けて送信する If-Range ヘッダーに記述する容量を、圧縮されたとき
のものにしておく必要があるようなんです。

たとえば生では10バイトのDATをGZip圧縮して送信してもらったとします。
GZip圧縮をかけた結果5バイトに圧縮されたとします。
すると次回以降差分要求をするときに If-Range ヘッダーには10バイトでは
なく5バイトと記述しておかないと正しく差分データが受信できないようなんです。
そうでないと鯖からエラーコード416が返されてしまうようです。

これは結構ゆゆしき問題なんです。
ローカルに保存したDATは当然GZip圧縮を解除した状態なので、GZip圧縮を
かけたときのサイズを If-Range ヘッダーに記述するには、圧縮されたときの
のデータサイズをDATファイルごとにどこかに記憶しておく必要があるんです。
管理が面倒になるうえにこの圧縮されたときのサイズのデータが吹き飛べば
DATは最初から再取得しなければならなくなるんですね。

GZip圧縮は綺麗さっぱり忘れて無圧縮状態でデータを送信するようにした
ほうがいいってことなんでしょうか？
あるんです。
930 ：デフォルトの名無しさん ：2008/10/01(水) 13:57:09: >>929
差分取得の時はAcceptEncodingにgzipを付けずに生で受け取る。
初回のレス1から読むときのみAcceptEncodingにgzipを付ける。
でホントにgzipだったら解凍する。生だったらそのまま。

ま、最初はgzip無視で作っちゃってもいいと思う。
君一人が非圧縮で受信したところでたいした負荷でもないし。
余裕出来たら、レス1から読むときはgzipで読むでいいのでは。
931 ：デフォルトの名無しさん ：2008/10/01(水) 14:00:54: あと、HTTPサーバーの基本知識をもう少し付けるべきだと思うけど、
独自仕様もあるので注意。
板移転はレスポンスにステータスコード301,302といったリダイレクトが返ってくるわけじゃない。
200が返ってきて、中のjavascriptの
window.href=移転先URL
を見ないと駄目。しかも移転先に、さらに移転先が書いてある場合も。
932 ：899 ：2008/10/01(水) 15:31:30: >>930
> 差分取得の時はAcceptEncodingにgzipを付けずに生で受け取る。
> 初回のレス1から読むときのみAcceptEncodingにgzipを付ける。
> でホントにgzipだったら解凍する。生だったらそのまま。

その手がありましたか(`･ω･´)！

言われてみれば圧縮されたgzipファイルを差分取得するっておかしな概念ですよね。
レスが加えられていくごとに圧縮ファイル全体はつど変化していくわけですし
そうなればif-Rangeで範囲指定をしても取得できるデータに誤差が生じるのは
当たり前です。

Janeといった一般的なブラウザも差分取得時は無圧縮で取得してたりするんでしょうか？

ちなみにC# + .NET2.0で開発していますがこれ幸いか落としてきたデータの
gzipを解凍する手順はプログラマーが意識しなくてもいいようです。
勝手に解凍してくれるようで普通にReadToEnd()で読めちゃったりしています。

>>931
了解です。移転の検出は実装したほうがよさそうですね。
933 ：デフォルトの名無しさん ：2008/10/01(水) 18:16:03: 何度でも書くけどHTTPの資料読もうな
脊髄反射で質問するのはもう止めような
934 ：デフォルトの名無しさん ：2008/10/01(水) 19:06:56: >>932
他のブラウザがどう動いてるかはパケットキャプチャを使って調べる。
935 ：デフォルトの名無しさん ：2008/10/02(木) 06:09:25: >>933
HTTPの資料嫁とか方向違うだろ
どう見ても言語側でHTTPアクセスをサポートするライブラリ使ってるっぽいし
936 ：デフォルトの名無しさん ：2008/10/02(木) 07:30:00: HTTPの資料読んでたら半分は質問減ったと思うが
C# + .NET2.0で開発してる人は読まないのか？
937 ：デフォルトの名無しさん ：2008/10/02(木) 08:20:43: >>935
HttpWebRequest/Responseは、HTTPの仕様を知ってはいるんだけど、
自分でリクエストを組み立てたりレスポンスヘッダを解析したり
chunk転送をデコードしたり、KeepAliveを管理するのが面倒な人向け。
938 ：デフォルトの名無しさん ：2008/10/02(木) 08:41:45: ごめん >>933だけで脊髄反射しちゃった
939 ：デフォルトの名無しさん ：2008/10/02(木) 13:53:29: HTTPの仕様は読む必要あるだろう
if-modified-sinceやらe-tag、クッキーの仕様とか知らんと話にならん。
俺も浅い知識で組んだせいで後の修正大変だった。
一番大変なのは2ちゃんのどこにも明記されてないような謎仕様と
トライアンドエラーで戦わないと行けないことだ。
940 ：デフォルトの名無しさん ：2008/10/02(木) 18:47:16: >>939
そういうのは、monazilla-ML(だっけ？)に入って聞いたほうが早いんじゃない？
941 ：デフォルトの名無しさん ：2008/10/02(木) 19:43:54: あれまだ機能してんのかな・・・
942 ：899 ：2008/10/02(木) 20:32:17: >>937
C# with .NET2.0の環境でもヘッダを解析したり構築したりして
送受信されてる奇特な方っていらっしゃるんですか？
943 ：デフォルトの名無しさん ：2008/10/03(金) 18:29:56: HTTPの意味もよく分からず開発を始めて質問しまくる人とか
人の忠告を聞かない人はよく見かけるね
944 ：デフォルトの名無しさん ：2008/10/03(金) 19:19:08: っ鏡
945 ：デフォルトの名無しさん ：2008/10/05(日) 10:16:41: >>942
プログラムの勉強をしたい人とか、生粋のプログラマとか。

車輪の再発明と言われるけどプログラムやプロトコルを勉強するには
一から作るのが一番良い方法だと思うよ。
作ったうえでライブラリを使うともっと理解が出来る、ただ使うだけなら疑問を持たず
「そうなんだ、こうしないとダメなんだ」で終わらしておく方が良い。
946 ：デフォルトの名無しさん ：2008/10/05(日) 11:29:25: HTTP1.0はシンプルだから、ソケット使って自前で通信したほうが
用途によってはコードも分かりやすいこともある
947 ：デフォルトの名無しさん ：2008/10/05(日) 14:02:00: 1.0 限定ならな… 1.1 になるととたんに面倒くさくなる。
クライアント側が GET ～ HTTP/1.0 しているのに、HTTP/1.1 で返事を返してくる
サーバって多いはずだけど、Apache ってどうだっけ？
948 ：デフォルトの名無しさん ：2008/10/05(日) 14:04:34: >>947
HTTP/1.1という返事は、「うちのサーバーは1.1まで対応してますよ」って意味であったはず
949 ：デフォルトの名無しさん ：2008/10/05(日) 17:10:33: よく読むスレを登録しておき、未読スレがないか一度に確認させるプログラムを
作ろうと思っているんですが、各スレを連続で読み込みするのにどのくらいの
時間をおけばいいものなんでしょうか？

それともそういうことは気にせず、いくつスレを登録してようと一度に一気に
読み込むプログラムを組んでしまっていいものなんでしょうか？

２ちゃんの方で明確な指針が掲載されていないと言うことは常識の範囲内で、
ということなんでしょうが、どのあたりが常識とか決まっているんでしょうか？
950 ：デフォルトの名無しさん ：2008/10/05(日) 17:11:44: ↑あと上記に絡んだ質問です。

過度に連続読み込みしたことで２ちゃん側からシャットアウトされる可能性って
ありますか？もしシャットアウトされたとしたらどんな返答が返ってくるんでしょうか？
シャットアウトされたことも知らずに続けて連続読み込みのリクエストを出し続ける
と後々問題になりそうなので・・・
951 ：デフォルトの名無しさん ：2008/10/05(日) 17:56:01: >>950
ばーぼんなんとかだったかな
952 ：デフォルトの名無しさん ：2008/10/05(日) 18:04:15: http://qb5.2ch.net/test/read.cgi/operate/1221391423/962
962 名前：鷲鴨 ★[] 投稿日：2008/09/15(月) 06:27:06 ID:???0 (PC)
みんなでツールで巡回しやがって
ボボン値も変更するか

巡回は負荷かかるから締め出し
953 ：デフォルトの名無しさん ：2008/10/05(日) 18:28:04: >>951
「ばーぼん」ですか・・・
ちょっとググッてきます。

>>952
とはいえ、きょうび巡回機能が無い２ちゃんブラウザなんてお話にならないかと・・・
954 ：デフォルトの名無しさん ：2008/10/05(日) 18:41:39: 未読チェックだけならsubject.txt取得だけでいいだろ
955 ：デフォルトの名無しさん ：2008/10/05(日) 19:27:55: >>954
チェックしたいスレが複数の板をまたがると
956 ：デフォルトの名無しさん ：2008/10/05(日) 20:54:45: 複数の板のsubject.txtを取得すればいいだけの話だあろ
957 ：デフォルトの名無しさん ：2008/10/05(日) 21:01:45: リードのみでも連続アクセスするとばーぼんへ飛ばされるんですね。
ばーぼん回避のためにスレ１つ読むごとに1秒間のウェイトを入れておこうとおもいます(´･ω･｀)
958 ：デフォルトの名無しさん ：2008/10/05(日) 21:02:25: バーボン飛ばされたらつなぎなおせばOK
959 ：デフォルトの名無しさん ：2008/10/05(日) 21:16:32: こういうことはあんま言っちゃいけんのかもしれんが
プロクシサーバを複数確保して巡回させればボボン回避は
十分可能なんじゃないか？
960 ：デフォルトの名無しさん ：2008/10/06(月) 02:28:47: 複数確保が簡単にできる環境は少ないんでは。
961 ：委員長 ◆/DABoneCRY ：2008/10/06(月) 02:43:13: 「ダメだ！辞めろ」と言うつもりはありませんが、
どれくらい時間をおけば「許される」というものではないと思います。
限界ギリギリを狙おうとするのではなく、可能な限り負荷をかけないよう
配慮する発想の方が健全だと思います。
962 ：デフォルトの名無しさん ：2008/10/06(月) 02:49:00: >>960
っサイバーシンドローム
963 ：デフォルトの名無しさん ：2008/10/06(月) 12:57:01: >>925
折角、GZIPInputStream調べてgzip転送に対応しようと思ったのに必要なかったのか｡･ﾟ･(ﾉД`)･ﾟ･｡
964 ：デフォルトの名無しさん ：2008/10/06(月) 19:27:18: >>925
gzip圧縮やってないってどこのサーバ？

>>963
今もAccept-Encodingにgzip設定すれば圧縮して返してくるから
クライアント側は対応しておく方がベターでしょう
965 ：デフォルトの名無しさん ：2008/10/06(月) 20:02:20: >>964
そうなん(・∀・)？実況専用ブラウザにしようと思ってるけど、じゃあそうしよう。
966 ：デフォルトの名無しさん ：2008/10/08(水) 18:24:57: 多くの２ちゃんブラウザでは鯖移転を自動的に検出して対応していますが、
これはどういう仕組みで追尾しているんでしょうか？

できればこの便利な機能をマイブラウザにも実装したいと思っています。
967 ：デフォルトの名無しさん ：2008/10/08(水) 18:29:33: <http://qb.2ch.net/operate/>　のソースコードとか見りゃ分かるはずだ
968 ：デフォルトの名無しさん ：2008/10/08(水) 18:42:55: > 板が移転した場合、/板のキー/のHTMLに移転先が書いてあるので、それを調べるのがよいかと。

http://age.s22.xrea.com/talk2ch/

HTMLに移転先が書かれているとのことですが、どの場所に書かれているのか決まっているんでしょうか？

> subject.txtが見つからない場合は、板が移転したと判断しても大丈夫でしょう。

あと移転したかしてないかは subject.txt があるかどうか調べればいいとのことですが、
たとえば先ほど

http://gimpo.2ch.net/army/
↓
http://anchorage.2ch.net/army/

に移転した板の、移転前のsubject.txtを調べてみると
http://gimpo.2ch.net/army/subject.txt
移転したはずなのにまだ存在しているようです（まっさらな状態ですが）。
これだとsubject.txtの有無で移転の有無を調べることができないかと思うのですが
一般的な２ちゃんぶらうざは何をもって移転したしないを判断しているんでしょうか？
969 ：デフォルトの名無しさん ：2008/10/08(水) 20:54:19: なぜ >>967を無視する。

location.hrefを辿ってくだけだ。
970 ：デフォルトの名無しさん ：2008/10/08(水) 23:25:53: http://qb.2ch.net/operate/

のHTMLソース内にlocation.hrefが見あたらないのはブラウザで読むと転送されてしまうからでしょうか？
971 ：デフォルトの名無しさん ：2008/10/08(水) 23:34:26: <html>
<head>
<script language="javascript">
window.location.href="http://qb3.2ch.net/operate/"</script>
<title>2chbbs..</title>
<meta http-equiv="Content-Type" content="text/html; charset=x-euc-jp">
</head>
<body bgcolor="#FFFFFF">
Change your bookmark ASAP.
<a href="http://qb3.2ch.net/operate/">GO !</a>
</body>
972 ：デフォルトの名無しさん ：2008/10/09(木) 01:19:47: >>971
どうも、やはりすぐに転送されたためにそのページは飛ばされて見えなかったようです。
973 ：デフォルトの名無しさん ：2008/10/09(木) 01:36:12: ところで上記のHTMLファイルのフルパスは

http://qb.2ch.net/operate/index.html

でよろしいでしょうか？
974 ：デフォルトの名無しさん ：2008/10/09(木) 12:32:26: >>973
Webサーバ(アパッチ？)の設定により、URLを/で止めた場合のアクセスは異なる
/で止めておけばWebサーバ側が設定によりindex.htmlとかindex.cgiとかを返してくれるから/で止めておけばいいと思う
975 ： ◆TWARamEjuA ：2008/10/09(木) 23:08:19: (´-`).｡ｏＯ(971を読めば判ると思うけれども。。。2ch鯖監視係。もそうしています。＠板移転自動追尾)
976 ：デフォルトの名無しさん ：2008/10/09(木) 23:26:38: どうもです。index.htmlは抜きでトライしてみます。
977 ：デフォルトの名無しさん ：2008/10/09(木) 23:41:37: window.location.href="http://qb3.2ch.net/operate/"</script>
これ最後のセミコロンがないね
JavaScriptってセミコロンなしでもいいんだっけ？
978 ：デフォルトの名無しさん ：2008/10/09(木) 23:49:18: いいんだよ
979 ：デフォルトの名無しさん ：2008/10/09(木) 23:56:32: グリーンダヨ
980 ：デフォルトの名無しさん ：2008/10/10(金) 00:58:02: 板移転ってDATファイルを読み込んだり板一覧を更新するときに毎回
location.hrefのところを読んで検出してるんですか？

それとも毎回検出するのは無駄ですか？
981 ：デフォルトの名無しさん ：2008/10/10(金) 01:11:50: http://menu.2ch.net/bbsmenu.html
が更新されてたらそれを取得するだけでいい。

bbsmenuが移転に対応してないときに検出すればそれだけで事足りる。
あとはユーザーに明示的に移転作業をさせたいときとか。
982 ：デフォルトの名無しさん ：2008/10/10(金) 15:09:42: 取得できなければ移転してんじゃね？
302ってなんだか良く分からんが。
983 ：デフォルトの名無しさん ：2008/10/10(金) 16:39:36: 302 Found

おそらく「移転したよ」という意味。
984 ：デフォルトの名無しさん ：2008/10/10(金) 21:02:18: 委員長空気・・・
985 ：デフォルトの名無しさん ：2008/10/10(金) 22:26:19: 本来404を返す状況で
ErrorDocumentが外部URLを指している場合
代わりに302が返る。

まめちしきな。
986 ：デフォルトの名無しさん ：2008/10/11(土) 01:06:11: >>985
> ErrorDocumentが外部URLを指している場合

ここのところよく分からないんだが
987 ：デフォルトの名無しさん ：2008/10/11(土) 02:36:47: >>986
http://httpd.apache.org/docs/2.2/ja/mod/core.html#errordocument

228KB

新着レスの表示

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

0ch BBS 2004-10-30