Ack für Fragment
Verwenden Sie das Ack for Fragment-Paket , um die Fragmentanforderung des Clients zu bestätigen.
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
Header
-
Reason-Code
-
Ersetzen Sie reason-code durch einen HTTP-Ursachencode. Die folgende Tabelle zeigt die typischen Ursachencodes für eine Antwort auf eine Fragmentanforderung . Eine Liste der HTTP-Ursachencodes finden Sie unter RFC 2616.
Ursachencode BESCHREIBUNG 200 OK. Die Anforderung wurde erfolgreich gesendet. 416 Range-Not-Satisfiable. Der Client hat ein Fragment gesendet, dessen Bereich nicht mit dem vorherigen Fragment zusammenhängend ist. -
Reason-description
-
Ersetzen Sie reason-description durch die HTTP-Beschreibung, die dem Ursachencode zugeordnet ist. Legen Sie z. B. reason-description auf OK fest, wenn reason-code 200 ist.
-
BITS-Packet-Type
-
Identifiziert dieses Antwortpaket als Ack-Paket.
-
BITS-Received-Content-Range
-
Nullbasierter Offset auf das nächste Byte, das der Server vom Client erwartet. Wenn das Fragment beispielsweise den Bereich 128 212 enthält, würden Sie den Bereich auf 213 festlegen.
-
BITS-Session-ID
-
Zeichenfolgen-GUID, die die Sitzung für den Client identifiziert. Ersetzen Sie {guid} durch den Sitzungsbezeichner, den der Client im Fragmentanforderungspaket gesendet hat. Wenn Sie den Sitzungsbezeichner nicht erkennen, legen Sie den BITS-Error-Code-Header auf BG_E_SESSION_NOT_FOUND fest.
-
BITS-Reply-URL
-
Enthält die URL zu den Antwortdaten eines Upload-Antwortauftrags. Fügen Sie diesen Header in die endgültige Fragmentantwort ein, nachdem der Upload abgeschlossen ist, und Sie erhalten ggf. eine Antwort von der Serveranwendung.
Verwenden Sie den Content-Range-Header aus der Fragment-Anforderung, um zu bestimmen, ob der Upload abgeschlossen ist. Der Upload ist abgeschlossen, wenn der Endoffset des Bereichswerts dem Wert der Gesamtlänge minus 1 entspricht.
Der BITS-Server veröffentlicht die Uploaddatei an die Serveranwendung, nachdem er festgestellt hat, dass der Upload abgeschlossen ist. Die Serveranwendung verarbeitet die Datei und generiert die Antwort. Der BITS-Server legt den Wert von BITS-Reply-URL auf die URL der Antwortdatei aus der Serveranwendung fest.
-
Inhaltslänge
-
Ersetzen Sie length durch die Anzahl der Bytes, die im Textkörper der Antwort enthalten sind. Content-Length ist erforderlich, auch wenn der Text der Antwort keinen Inhalt enthält.
-
BITS-Error-Code
-
Ersetzen Sie den Fehlercode durch eine Hexadezimalzahl, die einen HRESULT-Wert darstellt, der einem serverseitigen Fehler zugeordnet ist. Schließen Sie diesen Header nur ein, wenn der Grundcode nicht 200 oder 201 ist.
-
BITS-Error-Context
-
Ersetzen Sie error-context durch eine Hexadezimalzahl, die den Kontext darstellt, in dem der Fehler aufgetreten ist. Geben Sie die Hexadezimalzahl für BG_ERROR_CONTEXT_REMOTE_FILE (0x5) an, wenn der Server den Fehler generiert hat. Geben Sie andernfalls die Hexadezimalzahl für BG_ERROR_CONTEXT_REMOTE_APPLICATION (0x7) an, wenn der Fehler von der Anwendung generiert wurde, an die die Uploaddatei übergeben wird. Schließen Sie diesen Header nur ein, wenn der Grundcode nicht 200 oder 201 ist.
Bemerkungen
Wenn die Sitzung für einen Upload-Antwort-Auftrag vorgesehen ist, kann es zu einer Verzögerung kommen, bevor der Client die endgültige Antwort Ack for Fragment empfängt . Die Länge der Verzögerung hängt von der Zeit ab, die die Serveranwendung (Anwendung, in die der Server die Uploaddatei veröffentlicht) benötigt, um die Antwort zu generieren.