- PR -

プロキシサーバを経由してPDFファイルをダウンロードするとファイルが壊れる

投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-06-11 12:21
問題の切り分けの手法として、
APサーバの問題であるかを検証してみてはいかがでしょうか。
静的なPDFファイルを置いておいて、これのダウンロードが成功するか、失敗するか。

失敗するならプロキシ・ブラウザ間の問題であるし、
成功するならAPサーバのバグも考えられますね。

APサーバのバグと言っているのは、プロキシ経由のブラウザからのリクエストが、
壊れていて不正なPDFが生成されている可能性についてです。
ただ、ある程度切り分けが行われているようですので、
この辺は問題がないように思えますが。
バトー
会議室デビュー日: 2008/06/10
投稿数: 13
お住まい・勤務地: 埼玉
投稿日時: 2008-06-11 12:42
引用:

末記人さんの書き込み (2008-06-11 10:34) より:
こんにちは、3〜4年前ですが似たような現象に合ったことがあります。
その時は散々調べて、結局アドインの問題だったような記憶です。

Cns_minだったかな?JWORDを入れたときに入るBHO型のプラグインで、
その時はこれをアンインストールしたら正常に動作しました。

IE6無印では正常に動いてIE6のSP?を入れた端末で動かないという現象だった
と思います。

アドオンを全部無効にした状態でも現象はでますか?


最低限のアドオンのみにして実行してみましたが,やはり現象は変わらずでした。
このときIEで使用可能にしたアドインはAdobe PDF Reader Link Helperと
Shockwave Flash Objectの2つです。
残りは全て「アドオンの管理」画面から無効に設定し,IEを再起動後に確認しました。


引用:

unibonさんの書き込み (2008-06-11 11:01) より:
引用:

バトーさんの書き込み (2008-06-11 10:05) より:
wPdfPageはAspose.Pdf.Kitを使用してPDFファイルを作成していますが,そのクラスです。
初めはサーブレットのバグも考えたんです。
が,同じHTTPリクエストでFirefoxでは正常動作,IE6.0なら異常動作っていうのも,
プログラムの動作として考えると…。


引用:

バトーさんの書き込み (2008-06-10 12:26) より:
wRes.write(wPdfPage.toByteArray());
wPdfPage.close();


そのツールは知らないのですが、close する前に size や toByteArray を取得して大丈夫なのかな?と疑問に思いました。
(仕様次第であり、たとえば似たような名前のメソッドを持つ Java の java.io.ByteArrayOutputStream だったら close してもしなくても良いので、一概には言えませんが。)

引用:

バトーさんの書き込み (2008-06-11 10:05) より:
また,開発環境では再現しなくて,アプリケーションを公開しているサーバのみでしか
動作確認ができない状態です。
更に,既にユーザに使われているので,あまり極端なテストプログラムに差し替えるのも
難しい状態です。


私だったら wPdfPage の内容を Web サーバー内のファイルとして、逐一ログファイルとして記録していきます(ミリ秒単位の時刻をファイル名とするなど)。バグが発生したら、そのログファイルがすでに壊れているかどうかを遡って調べます。これだと、追加だけで済むので楽です。
プロキシーを通すかどうかで、バッファーのチャンクのリード・ライトのバイト数が違ったり、マルチスレッドの動きが違ってバグの出方が異なるなどが考えられます。

以上、あくまでも、wPdfPage を疑った場合の話なので、ネットワークやクライアント側の疑いは別途残ります。


すみません,その後ソースを再度調べてみたところ,WPdfPageはjava.io.ByteArrayOutputStreamでした。
ガセネタを書き込んでしまい,申し訳ありませんでした。


引用:

かつのりさんの書き込み (2008-06-11 12:21) より:
問題の切り分けの手法として、
APサーバの問題であるかを検証してみてはいかがでしょうか。
静的なPDFファイルを置いておいて、これのダウンロードが成功するか、失敗するか。

失敗するならプロキシ・ブラウザ間の問題であるし、
成功するならAPサーバのバグも考えられますね。

APサーバのバグと言っているのは、プロキシ経由のブラウザからのリクエストが、
壊れていて不正なPDFが生成されている可能性についてです。
ただ、ある程度切り分けが行われているようですので、
この辺は問題がないように思えますが。



静的PDFのダウンロードは同じサイトの別のサーブレットでは正常動作しています。
が,問題のサーブレットを実行している方では確認していませんのでやってみます。

#それにしてもIEとFirefoxでこんなにも動作が違うんですね。
#MicrosoftもIEの供給をやめてくれないかな。
KOX
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 142
投稿日時: 2008-06-11 14:12
たしかhttp1.0とIE6が絡んだ障害が昔あったはず。
その当時は確かWindowsUpdateでは落ちてこないので、
個別にパッチをあてていた気がします。
ソースは思い出せていないので、今回と同様かどうかはわかりません。
一応情報まで。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2008-06-11 15:00
そもそもServletコンテナってチャンク形式でレスポンスしますよね?
HTTP-HeaderでContent-Lengthを指定するにはあらかじめコンテンツのbyte数が分かっている必要があるから、動的コンテンツには不向き。
そのためのチャンク形式なんだけど、コレってHTTP1.1の機能のハズ。

なので、そもそもServletコンテナというか中継するWebサーバというか、そのあたりに対して
GET /hoge.pdf HTTP/1.0
なんてリクエストを投げた場合に、そもそもレスポンスが
HTTP/1.0 200 OK
となるはずで、1.1の時とは違うチャンク形式ではないパケットが帰ってくることが予見されて、
その時のブラウザの挙動や如何に、ということになるのでは。

HTTP1.0って今でも現役で使われているのか…。
バトー
会議室デビュー日: 2008/06/10
投稿数: 13
お住まい・勤務地: 埼玉
投稿日時: 2008-06-11 15:30
引用:

ひろ@yaさんの書き込み (2008-06-11 08:56) より:
パケットキャプチャして比較してみれば?


パケットキャプチャはしてみましたが,よくよく考えたら
プロキシの外で録らないといけないんですよね。
プロキシの内側で録ってしまいました。
これからキャプチャして比較してみます。
お返事が遅れて申し訳ありませんでした。


引用:

KOXさんの書き込み (2008-06-11 14:12) より:
たしかhttp1.0とIE6が絡んだ障害が昔あったはず。
その当時は確かWindowsUpdateでは落ちてこないので、
個別にパッチをあてていた気がします。
ソースは思い出せていないので、今回と同様かどうかはわかりません。
一応情報まで。


情報ありがとうございます。
調べてみます。


引用:

nagiseさんの書き込み (2008-06-11 15:00) より:
そもそもServletコンテナってチャンク形式でレスポンスしますよね?
HTTP-HeaderでContent-Lengthを指定するにはあらかじめコンテンツのbyte数が分かっている必要があるから、動的コンテンツには不向き。
そのためのチャンク形式なんだけど、コレってHTTP1.1の機能のハズ。

なので、そもそもServletコンテナというか中継するWebサーバというか、そのあたりに対して
GET /hoge.pdf HTTP/1.0
なんてリクエストを投げた場合に、そもそもレスポンスが
HTTP/1.0 200 OK
となるはずで、1.1の時とは違うチャンク形式ではないパケットが帰ってくることが予見されて、
その時のブラウザの挙動や如何に、ということになるのでは。

HTTP1.0って今でも現役で使われているのか…。


リクエストは以下のようなリクエストです。
POST http://hoge-server/hoge HTTP 1.1

しかし,レスポンスが
プロキシ経由の時:HTTP/1.0 200 OK
プロキシ非経由の時:HTTP/1.1 200 OK
となっているんです。
また,レスポンスにContent-Lengthを追加しても現象は変わらずでした。

クライアント側でできることってそれほどないと思うんですが,
IEのパッチによる問題ではないとしたらサーバサイドの問題?
プレミアム
会議室デビュー日: 2007/08/15
投稿数: 9
投稿日時: 2008-06-18 12:17
割とふるい情報なんですが、いがぴょんさんのページ内、

シンプルなダウンロードサーブレットの雛形
http://homepage2.nifty.com/igat/igapyon/diary/2005/ig050315.html

のコードサンプル内に、
コード:
                // Accept-Rangesとしてnoneを表明する。
                // AdobeReader 7.0は これが無いと正常に動作しない。
                response.addHeader("Accept-Ranges", "none");


という部分がありました。
(ブラウザではなく、AdobeReaderへの対処法のように見受けられますがー)
関連しますでしょうか?
バトー
会議室デビュー日: 2008/06/10
投稿数: 13
お住まい・勤務地: 埼玉
投稿日時: 2008-06-18 14:45
引用:

プレミアムさんの書き込み (2008-06-18 12:17) より:
割とふるい情報なんですが、いがぴょんさんのページ内、

シンプルなダウンロードサーブレットの雛形
http://homepage2.nifty.com/igat/igapyon/diary/2005/ig050315.html

のコードサンプル内に、
コード:
                // Accept-Rangesとしてnoneを表明する。
                // AdobeReader 7.0は これが無いと正常に動作しない。
                response.addHeader("Accept-Ranges", "none");


という部分がありました。
(ブラウザではなく、AdobeReaderへの対処法のように見受けられますがー)
関連しますでしょうか?


ありがとうございます。
該当するヘッダ情報を入れて実行してみましたが,現象は変わらずでした。
#プロキシを経由する/しないでこんなに動作が違っていいのでしょうか?

プロキシからサーバへのリクエストのパケットキャプチャをする環境が
やっと揃いましたので,パケットをキャプチャして比較してみます。
バトー
会議室デビュー日: 2008/06/10
投稿数: 13
お住まい・勤務地: 埼玉
投稿日時: 2008-10-03 14:26
@ITな会議室の皆さま、バトーです。

パケットキャプチャすると書いておきながら3ヶ月も返信が遅れまして
申し訳ありませんでした。
あの後、仕事が爆発し、一段落ついたらプロキシサーバが吹っ飛び、その後は
自分のマシンと次々に不幸が訪れまして…、しばらく燃え尽きておりました。(^^ゞ
閑話休題…。

プロキシサーバ上で外へ送られるパケットをキャプチャしてみました。
IEからとFirefoxからとでキャプチャしてみましたが,大きな違いは見受けられませんでした。
キャプチャした結果を以下に載せます。

IEのとき
コード:
..8.3...@1.g..E..e.j@...o3..Rr.......P..?Q ?..P.......
POST /xxxx/xxxx HTTP/1.0..
Accept: */*..
Accept-Language: ja..
Referer: http://xxxx.co.jp/xxxx.swf..
Content-Type: application/x-www-form-urlencoded..
Accept-Encoding: gzip, deflate..
User-Agent: Mozilla/4.0 (compatible; MSIE 60; Windows NT 5.1; SV1; .NET CLR 2.0.50727)..
Host: xxxxxx.co.jp..
Content-Length: 407..
Pragma: no-cache..
Cookie: xxxx_id=xxxx; xxxx_password=xxxx; xxxx_auth=%2Fcontents; 
        Coyote-2-caef96f2=caef96f4:0; xxxxSESSID=xxxx....
QUESTION=%E5%A4〜〜〜%BA%BA
&OPTION=H
&MODE=R
&TITLE=
&SELECT=A..              



Firefoxのとき
コード:
..8.3...@1.g..E....X@...`...Rr.......P.U......P...h*..
POST /xxxx/xxxx HTTP/1.0..
Host: xxxx.co.jp..
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3..
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8..
Accept-Encoding: gzip,deflate..
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7..
Keep-Alive: 300..
Referer: http://xxxx.co.jp/xxxx/xxxx.html?3..
Cookie: Coyote-2-caef96f2=caef96f4:0; xxxx_id=xxxx; xxxx_password=xxxx;
        xxxxSESSID=xxxx; xxxx_auth=xxxx..
Content-type: application/x-www-form-urlencoded..
Content-length: 407....
QUESTION=%E5%A4〜〜〜%BA%BA
&OPTION=H
&MODE=R
&TITLE=
&SELECT=A           



固有名詞が出ている部分やセキュリティ上問題になりそうな部分は伏せ字にさせて頂きました。
あと,[QUESTION=]の部分も無駄に長かったんではしょりました。
ちなみに設定されている内容はIEとFirefoxで同じ値が設定されてました。

以上ですが,何か思うところはありますでしょうか?
#rifererを送出しないようにしたら1回だけ正常に動作したんだよな〜。
#でも,その後は二度と正常に動作しなかった…。
#あれは夢だったんだろうか…
#
#やっぱりunibonさんの手を使うしかないかな?
#先方に相談してみるしかないか…。

スキルアップ/キャリアアップ(JOB@IT)