4

私はphpスクリプト（実際にはhttps://drupal.org/project/file_force）を持っています。これは、リンクをクリックしたユーザーに、正しいヘッダーを応答に追加してそのリンクをダウンロードさせるように強制しています。

このリンクは 90% の確率で正常に機能します。時折、誤ったコンテンツ長が渡されるため、ユーザーは切り捨てられたように見えるファイルを取得します。エラーは特定のファイルで一貫して発生しますが、それらのファイルを再アップロードすると、新しいインスタンスにエラーが表示されない可能性があるため、これはファイルの問題ではなく、キャッシュのどこかにあると思われます。そのため、毎回 clearstatcache() を実行しても無駄でした。奇妙なのは、php が正しいファイル サイズを渡していること、または、挿入する文字列をログ ファイルに渡すときだと言っていることです。

関連するコードは次のとおりです。

  clearstatcache();
  return array(
    'Content-Type: ' . $mimeinfo,
    'Content-Disposition: ' . $disposition . '; filename="' . basename($filepath) . '";',
    // Content-Length is also a good header to send, as it allows the browser to
    // display a progress bar correctly.
    // There's a trick for determining the file size for files over 2 GB. Nobody
    // should be using this module with files that large, but… the sprintf()
    // trickery makes sure the value is correct for files larger than 2GB. See
    // note at http://php.net/filesize
    'Content-Length: ' . sprintf('%u', filesize($filepath)),
  );

動作していないファイルに対する sprintf('%u', filesize($filepath)) からのサンプル出力は、ブラウザがそれを見るようになったときに2682059何らかの形で変換されます。1740048

sprintf 関数を無駄に削除しようとしました。また、Content-Length 宣言をまったく含めないようにしましたが、とにかく誰かが間違った値に関連付けられています。この最後の証拠は、他のコードがここで設定しているコンテンツ ヘッダーをオーバーライドしていることを示唆している可能性がありますが、その理論をテストするために上記のコードで変更した他のヘッダーはそのままにしてあるようです。

どこを見ればよいか、何か考えはありますか？

4

2 に答える 2

2

問題を解決しました。

Drupal 内の別のモジュールが独自の content-length ヘッダーを追加し、ファイルから直接ではなくデータベースから値を取得しており (奇妙なことに)、それがダウンストリームで発生していたことが判明しました。モジュールがヘッダーを取得する順序を逆にすることで、問題は解消されました。問題のあるモジュールに対してバグレポートを提出しました。

于 2013-10-30T15:14:33.663 に答える