-PR-
解決済み

ブラウザのファイル転送終了判断

  • 困ってます
  • 質問No.22531
  • 閲覧数286
  • ありがとう数3
  • 気になる数0
  • 回答数5
  • コメント数0

お礼率 20% (1/5)

IEやネットスケープといったブラウザは,あるコンテンツを転送したとき,ファイルの転送が終了したことをどうやって把握しているのでしょうか?
HTTP GETで取得を開始した後,TCPのコネクションを切る判断をどうやってしているのか知りたいのです.
HTTPプロトコルのRFC定義で決められているのでしょうか?
もしご存知の方いらっしゃいましたら教えてください.
通報する
  • 回答数5
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

質問者が選んだベストアンサー

  • 回答No.5
レベル11

ベストアンサー率 55% (155/280)

HTTP1.1 では、hyde-la さんのいうように、他の手段も定義されてますね。
現実に使われてるかどうかはわかりませんけど…

ただ、http://www.asahi.com/ を見てみましたけど、IE 5.5 と unix 上の NN
4.76 で調べたかぎりでは、複数のコンテンツを1セッションで取得している例
がみつかりませんでした。"/" の取得に限っては、確かに Content-Length は
ありませんでしたが、それ以外の *.gif なんかの取得には全部付加されてい
ましたよ。
お礼コメント
ma-chang

お礼率 20% (1/5)

いろいろありがとうございます.
もう少しいろいろ調べてみます.
また質問させていただくこともあるかと思いますが
よろしくお願いいたします.
投稿日時 - 2000-12-27 21:32:46
-PR-
-PR-

その他の回答 (全4件)

  • 回答No.1
レベル11

ベストアンサー率 55% (155/280)

結論をいえば、ご想像のとおり、RFC2616で規定されています。

単純にHTTP1.0的なGETしかしない場合には、1個取得した段階でサー
バー側が切断してしまいますので、それで判断できますが、
HTTP1.1では複数個を連続して取得できるので、それぞれの内容に
先立ってサイズが通知され、それを利用します。

RFC2616を全部読むのは大変だと思います。HTTPを専門に扱う書籍
もありますので、これを参考にしてはいかがでしょう?
「HTTP詳説」P.S.ヘスマン(ピアソン・エデュケーション)
補足コメント
ma-chang

お礼率 20% (1/5)

ご回答ありがとうございます.

現在いろいろ試しているのですが,サーバにapacheを用意して,IEでGETをして(例えばGET http://***.ne.jp/~hoge/pic.gif HTTP/1.0)
その転送をtcpdumpなどで見ていると,明らかに1つのフロー(TCPコネクション)で順次,複数コンテンツの転送が行われているんですよね.たとえばサーバが必ずContent-Lengthを通知してくれるのであれば全体のサイズがわかっているのでコンテンツの転送終了が確認できますが,そうでないのになぜIEはそのコンテンツの転送終了を判断できたのか?というのが気になります.しかもHTTP1.0を利用しているのにです.
実装方法に依存しているのかもしれませんが,その手法が謎のままなのです.
投稿日時 - 2000-12-27 12:48:26


  • 回答No.2
レベル10

ベストアンサー率 28% (42/146)

ファイルの転送と終了に関しては、HTTPじゃなくて
TCPなのではないでしょうか?
・・・と今までは漠然とそう思ってたのですが、
ちょっとRFCを読んでみたらですね、
ひょっとしてRFC1945のセクション6が怪しいかなぁ、と。

基本的に一つずつファイルを要求し、完了し次第切る。
その完了の目安としてのことをおっしゃっているなら
多分同セクション6に記述されているresponseでしょうか。
  • 回答No.3
レベル11

ベストアンサー率 55% (155/280)

HTTP1.0 でも、指定によって複数個取得することは可能です。
HTTP1.0 の場合は、Content-Length かサーバー側の切断以外には、
長さを知る方法はありませんので、複数個の転送があるときは、
Content-Length は必ず通知されるはずですが…

そうじゃない例があったのでしょうか?
どうやって確認されたでしょうか?
補足コメント
ma-chang

お礼率 20% (1/5)

Content-Lengthはサーバ側が付けるかつけないか決定しているようなので,
(asahi.comなんかをみていると,だいたいCLを付けずにHTTP/1.0 200 OKを返してくる)
基本的にサーバがCLを付けてくれた場合は,1つのflowに複数コンテンツを流すことができる.
付けてくれなかった場合は,おとなしくサーバ側からのTCPをFINを待つということになるのでしょうか?

そうすると,HTTPというプロトコルは,TCPの切断をサーバ側から通知されるまではそのコンテンツが転送完了したかどうかわからないというかなり不完全なプロトコルのようなきがするのですが・・・.

ちなみにtcpdumpでパケット収集後,ethereal(http://www.ethereal.com/)でフローを抽出しています.

そのなかでたまにCLがついていないのにもかかわらず,1flowで複数コンテンツが転送されるのを確認しています.
投稿日時 - 2000-12-27 16:26:36
  • 回答No.4
レベル10

ベストアンサー率 28% (42/146)

思いっきりハズしてしまいましたhyde-laです。
ちょっと調べてみました。

HTTPのメッセージ終了を決定する方法は、他にもいくつかあるようです。

特にmultipartの場合は事前にメッセージ長を決定出来ない為、
lengthが付加されないそうです。
その場合は、transfer-encodingにchunkを指定して、
それでメッセージの終わりを指定することが出来るようです。

この辺は、3.6章のchunkedの説明、4.4章のContent-Lengthの説明、
あと7.2.2章のNoteを読むと解るようです。

また、HTTP/1.1のブラウザは"chunked"Transfer-encodingの内容を理解出来ねばならず、
それが駄目な場合は、その転送コーディングは無視されるべきだ・・・
と書いてあります。

以下の日本語訳をどうぞ。
このQ&Aで解決しましたか?
AIエージェント「あい」

こんにちは。AIエージェントの「あい」です。
あなたの悩みに、OKWAVE 3,500万件のQ&Aを分析して最適な回答をご提案します。

関連するQ&A
-PR-
-PR-
このQ&Aにこう思った!同じようなことあった!感想や体験を書こう
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-
-PR-
-PR-

特集


専門家があなたの悩みに回答!

-PR-

ピックアップ

-PR-
ページ先頭へ