- - PR -
ファイル保存キャンセルをキャッチ
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-12-14 20:37
う〜む。面白いアイデアだと思ったのですが。
では、ステータスコード201を使う手はどうでしょうか？ こちらも妄想なのですが、ブラウザの挙動次第では検出率を高められるかも。 http://suika.fam.cx/~wakaba/-temp/wiki/wiki?201 302とか303とかだとリダイレクトしちゃってからダイアログだろうから 2xx系じゃないと駄目でしょうね。 1xx系もOKだしてない状態だからダイアログでないような気がする。 | ||||||||
|
投稿日時: 2006-12-15 15:40
いいだしっぺの法則で簡単な実験をしておきました。
実験結果を報告しておきます。 201 Created を返した場合と、202 Accepted を返した場合、IEでは 「Internet Explorer では、xxxxxをダウンロードできません。 このインターネットのサイトを開くことができませんでした。 要求されたサイトが使用できないか、見つけることができません。 後でやり直してください。」 というダイアログが表示されました。 対応していないようですね…。 206 Partial Content を返した場合、レスポンスで返したContent-Rangeの 次の範囲を再度取得しに来ることを期待していたのですが、 リクエストヘッダRangeを指定したリクエストが再送されてくることはなく、 初期の206の際に書き出した内容だけの後ろの切れたファイルが保存されました。 う〜む。 IEってのはこういうステータスコードに対応していないもんなんですかねぇ。 302 Found、303 See Otherを使ったケースでは リダイレクト要求がされてから保存場所指定のダイアログが開くので 使えないことが分かりました。こちらは予想通りですね。 | ||||||||
|
投稿日時: 2006-12-15 16:11
ちなみに、キャンセルをキャッチできたとして、
どのような状況で何のために利用するんでしょうか？ | ||||||||
|
投稿日時: 2006-12-15 16:22
「ちゃんと保存しろ！」とでも出したいんでしょうか。
とりあえず無理ですね。 ダイアログが出るときには、すでにローカルのテンポラリにダウンロードが終わってますし。 | ||||||||
|
投稿日時: 2006-12-15 16:34
無理なのは承知の上ですよ
とありますから、最初からおまけ的な話だと解釈しています。 インギさんが2006-12-14 18:56に 「サーバサイドで IOException を検出できない様なケースではムリ」 と発言した時点で確実な検出はできないという話は既出ですよね。 用途についてですが、ダウンロードのカウンタみたいなものを作った際に 数字の精度がやや上がる程度とか、途中キャンセルされる率が どのぐらいか調べてみる、というぐらいの用途かなぁ。 なにぶん、原理的に確実な検出ができないので参考値にしかなり得ないと思います。 # そういえばスレ主の反応がないですね。 | ||||||||
|
投稿日時: 2006-12-15 16:46
ああ、やっぱり無粋なツッコミでしたね。 なんか、みなさん「楽しそう（？）」だったのでアレかなーと思いつつも 解決することによる利点がなにかあるのかな、とおもいまして。
うーん、「エンドユーザの利益」にはなりそうにないかも。 # 手段のためならば目的は選ばない みたい。 | ||||||||
|
投稿日時: 2006-12-15 17:05
う〜ん、業務システムであればデータファイルを
確実に取得したかを管理したいっていう要望もありそう・・・ 逆に、１人あたり１度のみという限定をしたい場合もありですね。 | ||||||||
|
投稿日時: 2006-12-15 17:13
これって「確実に検出できる」という前提がついた場合ですよね。 原理的に確実な検出は無理なので業務システムで使うことはできないのでは。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。