後臺智能傳輸服務和亞馬遜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

回答

相關問題