后台智能传输服务和 Amazon S3答案

【问题标题】：Background Intelligent Transfer Service and Amazon S3后台智能传输服务和 Amazon S3
【发布时间】：2011-01-13 21:51:47
【问题描述】：

我正在使用 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 状态 403 - 未授权。网址在浏览器中工作文件。

这是来自 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

与来自网络浏览器的唯一区别是请求类型。 Firefox 发出 GET 请求，BITS 发出 HEAD 请求。 Amazon S3 HEAD 请求和查询字符串身份验证是否存在任何问题？

问候，布拉兹

【问题讨论】：

看看 SharpBits 生成的 HTTP 请求到底是什么样子会很有帮助。你也许可以使用调试器来解决这个问题。
我认为 HEAD 请求可能有问题，也许 S3 没有正确处理它。 BITS 使用范围协议标头。
这些在 cmets 中的事实使它们几乎无法理解。您为什么不编辑您的问题并在其中包含标题，并使用代码块对其进行格式化。
这是一个很好的询问方式，用户*。
是的。头是一个问题。签名参数是一个散列，其中还包括一个 http METHOD。将签名生成器更改为使用 HEAD 时，它工作正常。但是还有另一个主要问题，在 HEAD 之后 BITS 发送的下一个请求是 GET，现在我又遇到了签名问题:)。不幸的是，我无法传递不同的 HEAD 和 GET 请求 URL。我看到的唯一解决方案是代理？..

标签： http-headers amazon-s3 microsoft-bits bits-service

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

在开始下载之前，BITS 会向服务器发送 HTTP HEAD 请求，以计算远程文件的大小、时间戳等。这对于 BranchCache-based BITS transfers 尤其重要，这也是服务器端 HTTP HEAD 支持的原因被列为HTTP requirement for BITS downloads。

话虽如此，如果满足以下任一条件，BITS 会绕过 HTTP HEAD 请求阶段，立即发出 HTTP GET 请求：

BITS 作业配置了BITS_JOB_PROPERTY_DYNAMIC_CONTENT 标志。
BranchCache 已禁用并且 BITS 作业包含单个文件。

解决方法 (1) 是最合适的，因为它不会影响系统中的其他 BITS 传输。

对于解决方法 (2)，可以通过 BITS 的 DisableBranchCache 组策略禁用 BranchCache。在进行任何组策略更改后，您需要在提升的命令提示符下执行“gpupdate”，否则更改需要大约 90 分钟才能生效。

【讨论】：