后台智能传输服务和亚马逊S3

我正在使用SharpBITS从AmazonS3下载文件。后台智能传输服务和亚马逊S3

> // 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-未授权。 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

来源

2010-02-06 Blaz Lipuscek

准确地查看SharpBits生成的HTTP请求的样子会很有帮助。您可以使用调试器将其解决。 – 2010-02-06 17:31:48

我认为HEAD请求可能存在问题，也许S3无法正确处理它。 BITS使用范围协议标头。 – 2010-02-06 18:10:31

事实上，这些在评论中，使他们几乎无法理解。你为什么不编辑你的问题，并在那里包含标题，并用代码块格式化。 – 2010-02-06 18:11:14

你也许是正确的，代理是解决这个问题的唯一途径。 BITS使用HEAD请求获取内容长度并决定是否要分块文件下载。然后它执行GET请求来实际检索文件 - 有时整个文件足够小，否则使用范围标题。

如果你可以使用代理或其他技巧来给它任何类型的HEAD请求响应，它应该会变得没有问题。即使HEAD请求伪造了虚构的内容长度，BITS也会转到GET。在这种情况下，您可能会看到重复的GET请求，因为如果第一个GET请求返回的内容长度比原始HEAD请求长，则BITS可能会决定“哦，废话，我最好把它封存起来。”

鉴于这一点，我有点惊讶它不够聪明，从HEAD请求上的403错误中恢复，仍然继续进行GET。这份工作的实际行为是什么？你有没有试过用bitsadmin/monitor来看它？如果工作处于瞬态错误状态，则可能需要大约20分钟才能完成并最终恢复。

来源

2010-06-29 06:33:54

在开始下载之前，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的DisableBranchCache组策略禁用BranchCache。执行任何组策略更改后，您需要从提升的命令提示符执行“gpupdate”，否则将需要大约90分钟才能使更改生效。

来源

2018-01-12 22:53:20

后台智能传输服务和亚马逊S3

回答

相关问题