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状态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

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

问候，Blaz

Answer 1

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

如果您可以使用代理或其他技巧为HEAD请求提供任何类型的响应，它应该会被取消。即使HEAD请求伪造成虚构的内容长度，BITS也会继续进行GET。在这种情况下你可能会看到重复的GET请求，因为如果第一个GET请求返回的内容长度超过了原始的HEAD请求，BITS可能会决定“哦，废话，毕竟我最好将其打包。”

考虑到这一点，我有点惊讶，它不够聪明，无法从HEAD请求中的403错误中恢复，仍然继续前进到GET。这份工作的实际行为是什么？您是否尝试过使用bitsadmin / monitor进行观看？如果工作处于暂时错误状态，它可能会持续约20分钟，然后最终恢复。

Answer 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 AND BITS作业包含单个文件。

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

对于解决方法（2），可以通过BITS＆＃39;来禁用BranchCache。 DisableBranchCache小组政策。你需要做＆＃34; gpupdate＆＃34;在进行任何组策略更改后，从提升的命令提示符开始，或者需要大约90分钟才能使更改生效。

后台智能传输服务和Amazon S3

2 个答案: