片段的 Ack
使用 Ack for Fragment 封包來確認用戶端的 Fragment 要求。
reason-code reason-description
BITS-Packet-Type: Ack
BITS-Session-Id: {guid}
BITS-Received-Content-Range: range
BITS-Reply-URL: url
Content-Length: length
BITS-Error-Code: error-code
BITS-Error-Context: error-context
標題
-
reason-code
-
將 reason-code 取代為 HTTP 原因碼。 下表顯示 回應 Fragment 要求的一般原因代碼。 如需 HTTP 原因代碼的清單，請參閱 RFC 2616。
原因代碼 描述 200 正常。 要求成功。 416 Range-Not-Satisfiable。 用戶端傳送的片段範圍與前一個片段不連續。 -
reason-description
-
將 reason-description 取代為與原因代碼相關聯的 HTTP 描述。 例如，如果 reason-code 為 200，請將原因描述設定為 [確定]。
-
BITS-Packet-Type
-
將此回應封包識別為 Ack 封包。
-
BITS-Received-Content-Range
-
伺服器預期用戶端傳送的下一個位元組以零起始的位移。 例如，如果片段包含範圍 128 212，您可以將範圍設定為 213。
-
BITS-Session-Id
-
識別用戶端會話的字串 GUID。 將 {guid} 取代為用戶端在 片段 要求封包中傳送的會話識別碼。 如果您無法辨識會話識別碼，請將 BITS-Error-Code 標頭設定為 BG_E_SESSION_NOT_FOUND。
-
BITS-Reply-URL
-
包含上傳-回復作業之回復資料的 URL。 上傳完成後，請將此標頭包含在最終片段回應中，並視需要從伺服器應用程式收到回應。
使用 Fragment 要求的 Content-Range 標頭來判斷上傳是否完成。 如果範圍值的結束位移等於總長度值減一，上傳就會完成。
BITS 伺服器會在判斷上傳完成之後，將上傳檔案張貼至伺服器應用程式。 伺服器應用程式會處理檔案並產生回復。 BITS 伺服器會從伺服器應用程式將 BITS-Reply-URL 的值設定為回復檔案的 URL。
-
Content-Length
-
將 length 取代為回應主體中包含的位元組數目。 內容長度是必要的，即使回應主體不包含內容也一樣。
-
BITS-Error-Code
-
以十六進位數位取代錯誤碼，代表與伺服器端錯誤相關聯的 HRESULT 值。 只有在 reason-code 不是 200 或 201 時，才包含此標頭。
-
BITS-Error-CoNtext
-
以十六進位數位取代錯誤內容，代表發生錯誤的內容。 如果伺服器產生錯誤，請指定 BG_ERROR_CONTEXT_REMOTE_FILE (0x5) 的十六進位數位。 否則，如果上傳檔案傳遞至的應用程式產生錯誤，請指定 BG_ERROR_CONTEXT_REMOTE_APPLICATION (0x7) 的 十六進位數位。 只有當原因碼不是 200 或 201 時，才包含此標頭。
備註
如果會話適用于上傳-回復作業，則用戶端在收到 Fragment 回應的最終 Ack 之前可能會有延遲。 延遲的長度取決於伺服器應用程式 (應用程式在上傳檔案) 產生回復所花費的時間量。