后台智能传输服务和 Amazon S3

Question

我正在使用 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 请求和查询字符串身份验证是否存在任何问题？

问候， 布拉兹

Answer 1

您可能是对的，代理是解决此问题的唯一方法。BITS 使用 HEAD 请求来获取内容长度并决定是否要对文件下载进行分块。然后，它执行 GET 请求来实际检索文件 - 如果文件足够小，有时会检索整个文件，否则会使用范围标头。

如果你可以使用代理或其他一些技巧来给它任何类型的 HEAD 请求响应，它应该会摆脱困境。即使 HEAD 请求是用虚构的内容长度伪造的，BITS 也会转移到 GET。在这种情况下，您可能会看到重复的 GET 请求，因为如果第一个 GET 请求返回的内容长度比原始 HEAD 请求长，那么 BITS 可能会决定“哦，糟糕，毕竟我最好将其分块”。

鉴于此，我有点惊讶它不够智能，无法从 HEAD 请求上的 403 错误中恢复并仍然继续执行 GET。该工作的实际行为是什么？您是否尝试过使用bitsadmin /monitor 来观看它？如果作业处于暂时错误状态，它可能会持续大约 20 分钟，然后最终恢复。