http-headers - 后台智能传输服务和 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 请求以实际检索文件 - 如果文件足够小，有时作为一个整体，否则使用范围 header 。

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

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