■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50
monazilla Part 5
- 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