5

SharpBITS を使用して、AmazonS3 からファイルをダウンロードしています。

> // Create new download job. BitsJob
> job = this._bitsManager.CreateJob(jobName, JobType.Download);
> // Add file to job.
> job.AddFile(downloadFile.RemoteUrl, downloadFile.LocalDestination);
> // Resume
> job.Resume();

認証を必要としないファイルに対して機能します。ただし、AmazonS3 ファイル要求の認証クエリ文字列を追加するとすぐに、サーバーからの応答は http state 403 -unauthorized になります。URL はブラウザーでファイルを動作させます。

BIT サービスからの HTTP 要求は次のとおりです。

HEAD /mybucket/6a66aeba-0acf-11df-aff6-7d44dc82f95a-000001/5809b987-0f65-11df-9942-f2c504c2c389/v10/summary.doc?AWSAccessKeyId=AAAAZ5SQ76RPQQAAAAA&Expires=1265489615&Signature=VboaRsOCMWWO7VparK3Z0SWE%2FiQ%3D HTTP/1.1
Accept: */*
Accept-Encoding: identity
User-Agent: Microsoft BITS/7.5
Connection: Keep-Alive
Host: s3.amazonaws.com

Web ブラウザーからのものとの唯一の違いは、要求の種類です。Firefox は GET リクエストを行い、BITS は HEAD リクエストを行います。Amazon S3 HEAD リクエストとクエリ文字列認証に問題はありますか?

よろしく、ブレイズ

4

2 に答える 2

2

プロキシがこれを回避する唯一の方法であることはおそらく正しいでしょう。BITS は HEAD 要求を使用してコンテンツの長さを取得し、ファイルのダウンロードをチャンクするかどうかを決定します。次に、実際にファイルを取得するために GET 要求を実行します。ファイルが十分に小さい場合は全体として、そうでない場合は範囲​​ヘッダーを使用して取得します。

プロキシまたはその他のトリックを使用して HEAD リクエストに何らかの応答を与えることができれば、スタックは解消されるはずです。架空のコンテンツ長で HEAD リクエストが偽装された場合でも、BITS は GET に移行します。このような場合、重複した GET 要求が表示されることがあります。最初の GET 要求が元の HEAD 要求よりも長いコンテンツ長を返した場合、BITS は「ああ、結局これをチャンクしたほうがいい」と判断する可能性があるためです。

それを考えると、HEAD リクエストで 403 エラーから回復して GET に進むほどスマートではないことにちょっと驚いています。仕事の実際の振る舞いは何ですか？bitsadmin /monitor で見てみましたか? ジョブが一時的なエラー状態にある場合、約 20 分間それを実行し、最終的に回復する可能性があります。

于 2010-06-29T06:33:54.807 に答える