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

与来自 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 回答
1

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

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

  1. BITS 作业使用BITS_JOB_PROPERTY_DYNAMIC_CONTENT标志进行配置。
  2. BranchCache 已禁用并且BITS 作业包含单个文件。

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

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

于 2018-01-12T22:53:20.523 回答