[MC-BUP]:
Background Intelligent Transfer Service (BITS) Upload Protocol
Intellectual Property Rights Notice for Open Specifications Documentation
Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit
Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Revision Summary
Date / Revision History / Revision Class / Comments8/10/2007 / 0.1 / Major / Initial Availability
9/28/2007 / 0.2 / Minor / Clarified the meaning of the technical content.
10/23/2007 / 1.0 / Major / Updated and revised the technical content.
11/30/2007 / 1.0.1 / Editorial / Changed language and formatting in the technical content.
1/25/2008 / 1.0.2 / Editorial / Changed language and formatting in the technical content.
3/14/2008 / 1.0.3 / Editorial / Changed language and formatting in the technical content.
5/16/2008 / 1.0.4 / Editorial / Changed language and formatting in the technical content.
6/20/2008 / 1.1 / Minor / Clarified the meaning of the technical content.
7/25/2008 / 1.1.1 / Editorial / Changed language and formatting in the technical content.
8/29/2008 / 1.1.2 / Editorial / Changed language and formatting in the technical content.
10/24/2008 / 1.1.3 / Editorial / Changed language and formatting in the technical content.
12/5/2008 / 1.2 / Minor / Clarified the meaning of the technical content.
1/16/2009 / 2.0 / Major / Updated and revised the technical content.
2/27/2009 / 2.0.1 / Editorial / Changed language and formatting in the technical content.
4/10/2009 / 3.0 / Major / Updated and revised the technical content.
5/22/2009 / 3.1 / Minor / Clarified the meaning of the technical content.
7/2/2009 / 3.1.1 / Editorial / Changed language and formatting in the technical content.
8/14/2009 / 3.1.2 / Editorial / Changed language and formatting in the technical content.
9/25/2009 / 3.2 / Minor / Clarified the meaning of the technical content.
11/6/2009 / 3.3 / Minor / Clarified the meaning of the technical content.
12/18/2009 / 3.3.1 / Editorial / Changed language and formatting in the technical content.
1/29/2010 / 3.4 / Minor / Clarified the meaning of the technical content.
3/12/2010 / 3.4.1 / Editorial / Changed language and formatting in the technical content.
4/23/2010 / 4.0 / Major / Updated and revised the technical content.
6/4/2010 / 5.0 / Major / Updated and revised the technical content.
7/16/2010 / 6.0 / Major / Updated and revised the technical content.
8/27/2010 / 7.0 / Major / Updated and revised the technical content.
10/8/2010 / 7.0 / None / No changes to the meaning, language, or formatting of the technical content.
11/19/2010 / 7.0 / None / No changes to the meaning, language, or formatting of the technical content.
1/7/2011 / 8.0 / Major / Updated and revised the technical content.
2/11/2011 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
3/25/2011 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/6/2011 / 8.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/17/2011 / 8.1 / Minor / Clarified the meaning of the technical content.
9/23/2011 / 8.1 / None / No changes to the meaning, language, or formatting of the technical content.
12/16/2011 / 9.0 / Major / Updated and revised the technical content.
3/30/2012 / 9.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/12/2012 / 9.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/25/2012 / 9.1 / Minor / Clarified the meaning of the technical content.
1/31/2013 / 9.1 / None / No changes to the meaning, language, or formatting of the technical content.
8/8/2013 / 10.0 / Major / Updated and revised the technical content.
11/14/2013 / 10.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/13/2014 / 10.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/15/2014 / 10.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/30/2015 / 11.0 / Major / Significantly changed the technical content.
10/16/2015 / 11.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/14/2016 / 11.0 / None / No changes to the meaning, language, or formatting of the technical content.
Table of Contents
1Introduction
1.1Glossary
1.2References
1.2.1Normative References
1.2.2Informative References
1.3Overview
1.3.1Message Flow Common to Both Modes
1.3.2Message Flow for Upload Mode
1.3.3Message Flow for Upload-Reply Mode
1.3.4Message Flow Optional in Both Modes
1.3.4.1Canceling an Upload
1.3.4.2Uploading to an Alternate Server
1.4Relationship to Other Protocols
1.5Prerequisites/Preconditions
1.6Applicability Statement
1.7Versioning and Capability Negotiation
1.7.1Client to Server Upload
1.7.2Server to Client Download
1.7.3Back-End Client to Server Application
1.8Vendor-Extensible Fields
1.9Standards Assignments
2Messages
2.1Transport
2.2Upload Message Syntax
2.2.1Common Among the Message Types
2.2.1.1Standard HTTP Header Fields
2.2.1.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.2CREATE-SESSION Request
2.2.2.1Standard HTTP Header Fields
2.2.2.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.2.3Message Body
2.2.3Ack Response for CREATE-SESSION
2.2.3.1Standard HTTP Header Fields
2.2.3.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.3.3Message Body
2.2.4PING
2.2.4.1Standard HTTP Header Fields
2.2.4.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.4.3Message Body
2.2.5ACK for PING
2.2.5.1Standard HTTP Header Fields
2.2.5.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.5.3Message Body
2.2.6FRAGMENT
2.2.6.1Standard HTTP Header Fields
2.2.6.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.6.3Message Body
2.2.7ACK for FRAGMENT
2.2.7.1Standard HTTP Header Fields
2.2.7.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.7.3Message Body
2.2.8CLOSE-SESSION
2.2.8.1Standard HTTP Header Fields
2.2.8.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.8.3Message Body
2.2.9ACK for CLOSE-SESSION
2.2.9.1Standard HTTP Header Fields
2.2.9.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.9.3Message Body
2.2.10CANCEL-SESSION
2.2.10.1Standard HTTP Header Fields
2.2.10.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.10.3Message Body
2.2.11ACK for CANCEL-SESSION
2.2.11.1Standard HTTP Header Fields
2.2.11.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.11.3Message Body
2.2.12Notification Request to the Server Application
2.2.12.1Standard HTTP Header Fields
2.2.12.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.12.3Message Body
2.2.13Notification Response from the Server Application
2.2.13.1Standard HTTP Header Fields
2.2.13.2HTTP Header Fields Introduced by the BITS Upload Protocol
2.2.13.3Message Body
2.3Download Message Syntax
3Protocol Details
3.1Upload Client Details
3.1.1Abstract Data Model
3.1.1.1UploadEntityInfo
3.1.1.2HTTPUploader
3.1.2Timers
3.1.2.1Upload Request Timeout
3.1.2.2Upload Response Timeout
3.1.2.3Host Fallback Timeout
3.1.3Initialization
3.1.4Higher-Layer Triggered Events
3.1.4.1New Upload Request
3.1.4.2Pause Existing Upload
3.1.4.3Resume Existing Upload
3.1.4.4Cancel Existing Upload
3.1.5Message Processing Events and Sequencing Rules
3.1.5.1Action for States
3.1.5.1.1STATE_INIT
3.1.5.1.2STATE_CREATE_SESSION
3.1.5.1.3STATE_PING
3.1.5.1.4STATE_FRAGMENT
3.1.5.1.5STATE_COMPLETE
3.1.5.1.6STATE_CANCEL
3.1.5.1.7STATE_ERROR
3.1.5.1.8STATE_GET_REPLY
3.1.5.1.9STATE_SUSPEND
3.1.5.2Message Processing
3.1.5.2.1Common to All Message Types
3.1.5.2.2CREATE-SESSION Response
3.1.5.2.3PING Response
3.1.5.2.4FRAGMENT Response
3.1.5.2.5CLOSE-SESSION Response
3.1.5.2.6CANCEL-SESSION Response
3.1.6Timer Events
3.1.6.1Upload Request Timeout
3.1.6.2Upload Response Timeout
3.1.6.3Host Fallback Timeout
3.1.7Other Local Events
3.1.7.1Transport Error Occurred During the Transfer
3.2Upload Server Details
3.2.1Abstract Data Model
3.2.1.1BITSDirectoryConfig
3.2.1.2ServerPortListener
3.2.1.3BITSSessionManager
3.2.1.3.1Table of Active Sessions
3.2.1.4BITSSessionWrapper
3.2.2Timers
3.2.2.1BITS Session Timeout
3.2.3Initialization
3.2.4Higher-Layer Triggered Events
3.2.4.1BITS Uploads Are Enabled for a Given Virtual Directory
3.2.4.2BITS Uploads Are Disabled for a Given Virtual Directory
3.2.5Message Processing Events and Sequencing Rules
3.2.5.1Action for States
3.2.5.1.1STATE_INIT
3.2.5.1.2STATE_RECEIVE_FRAGMENTS
3.2.5.1.3STATE_NOTIFY
3.2.5.1.4STATE_WAIT_FOR_CLOSE
3.2.5.1.5STATE_COMPLETE
3.2.5.1.6STATE_CANCEL
3.2.5.2Message Processing
3.2.5.2.1General Rules for HTTP-Level Error Responses
3.2.5.2.2Message Flow
3.2.5.2.3Common Message Validation
3.2.5.2.4CREATE-SESSION REQUEST
3.2.5.2.5PING REQUEST
3.2.5.2.6FRAGMENT REQUEST
3.2.5.2.7CLOSE-SESSION REQUEST
3.2.5.2.8CANCEL-SESSION REQUEST
3.2.6Timer Events
3.2.6.1BITS Session Timeout
3.2.7Other Local Events
3.3Back-End Client Details
3.3.1Abstract Data Model
3.3.1.1Back-End Client's State
3.3.2Timers
3.3.2.1Notification Send Timeout
3.3.2.2Notification Receive Timeout
3.3.2.3Notification Receive Response Timeout
3.3.3Initialization
3.3.4Higher-Layer Triggered Events
3.3.5Message Processing Events and Sequencing Rules
3.3.5.1Common
3.3.5.2Action for States
3.3.5.2.1STATE_INIT
3.3.5.2.2STATE_SEND_HEADERS
3.3.5.2.3STATE_SEND_DATA
3.3.5.2.4STATE_RECEIVE_HEADERS
3.3.5.2.5STATE_RECEIVE_DATA
3.3.5.2.6STATE_COMPLETE
3.3.5.2.7STATE_ERROR
3.3.5.3Message Processing
3.3.5.3.1General Rules for HTTP-Level Error Responses
3.3.5.3.2Notification Response
3.3.6Timer Events
3.3.6.1Notification Send Timeout
3.3.6.2Notification Receive Timeout
3.3.6.3Notification Receive Response Timeout
3.3.7Other Local Events
3.4Server Application Details
3.4.1Abstract Data Model
3.4.2Timers
3.4.3Initialization
3.4.4Higher-Layer Triggered Events
3.4.5Message Processing Events and Sequencing Rules
3.4.5.1General Rules for HTTP-Level Error Responses
3.4.5.2Notification Request
3.4.6Timer Events
3.4.7Other Local Events
3.5Download Server Details
3.5.1Abstract Data Model
3.5.2Timers
3.5.3Initialization
3.5.4Higher-Layer Triggered Events
3.5.4.1Modify URL Content
3.5.5Message Processing Events and Sequencing Rules
3.5.5.1Receive GET Request
3.5.5.2Receive HEAD Request
3.5.6Timer Events
3.5.7Other Local Events
3.6Download Client Details
3.6.1Abstract Data Model
3.6.1.1STATE
3.6.2Timers
3.6.2.1Request Timeout
3.6.2.2Response Timeout
3.6.3Initialization
3.6.4Higher-Layer Triggered Events
3.6.4.1Pause Download
3.6.4.2Resume Download
3.6.4.3Cancel Download
3.6.5Message Processing Events and Sequencing Rules
3.6.5.1Common
3.6.5.2Action for States
3.6.5.2.1STATE_INIT
3.6.5.2.2STATE_SIZE
3.6.5.2.3STATE_SEARCH
3.6.5.2.4STATE_DOWNLOAD
3.6.5.2.4.1Download from the BITS Peer-Caching: Content Retrieval Protocol Server
3.6.5.2.4.2Download from Original Server
3.6.5.2.4.3Choosing Ranges
3.6.5.2.4.4Trimming a Request to a Single URL
3.6.5.2.5STATE_SUSPEND
3.6.5.2.6STATE_COMPLETE
3.6.5.3Message Processing
3.6.6Timer Events
3.6.6.1Request Timeout
3.6.6.2Response Timeout
3.6.7Other Local Events
3.6.7.1Result Found on Peers
4Protocol Examples
4.1Successful Upload
4.2Successful Upload-Reply with Bits-Host-Id and Back-End Notifications
5Security
5.1Security Considerations for Implementers
5.2Index of Security Parameters
6Appendix A: Product Behavior
7Change Tracking
8Index
1Introduction
This document is a specification for the Background Intelligent Transfer Service (BITS) Upload Protocol. This protocol is used to transfer large payloads from a client to a server or server to client over networks with frequent disconnections and to send notifications from the server to a server application about the availability of uploaded payloads. This protocol is layered on top of HTTP 1.1 and uses several standard HTTP headers and defines some new headers.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.
1.1Glossary
This document uses the following terms:
back-end client: A component of this protocol that sends the notifications to the server application.
BITS session: An entity collection of data on the server that maintains the state of a single instance of a BITS upload. More details about the session state and actions can be found in section 3.2.1.4.
BITS session ID: A GUID that identifies the BITS session on the server. See section 2.2.1.2 for more details.
BITS-Host-ID: An optional secondary server address. See section 2.2.3.2 for more information.
destination URL: The location to which the request entity is being uploaded. For more information, see [RFC1738].
entity: The payload of a transfer (by analogy to the definition in [RFC2616]).
globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the GUID. See also universally unique identifier (UUID).
origin server: The URL host name in the destination URL or an IPv6address (as specified in [RFC2373] Appendix B).
proxy: A network node that accepts network traffic originating from one network agent and transmits it to another network agent.
reply URL: The URL of the response entity.
request entity: The server's copy of an entity being uploaded from the client.
response entity: An entity that maintains the response data from the server application. See section 1.3.3 for more information.
server application: The application that listens to the notification URL in [MC-BUP] section 3.2.1.1. This is also called a back-end server.
Transport Layer Security (TLS): A security protocol that supports confidentiality and integrity of messages in client and server applications communicating over open networks. TLS supports server and, optionally, client authentication by using X.509 certificates (as specified in [X509]). TLS is standardized in the IETF TLS working group. See [RFC4346].
Universal Naming Convention (UNC): A string format that specifies the location of a resource. For more information, see [MS-DTYP] section 2.2.57.
upload-reply: A type of upload where the server application sends a response entity to the client upon receiving and processing the complete request entity. See section 1.3.3 for more information.
virtual directory: A URL prefix that corresponds to a physical directory on the server.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2References
Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.
1.2.1Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information.
[MS-BPCR] Microsoft Corporation, "Background Intelligent Transfer Service (BITS) Peer-Caching: Content Retrieval Protocol".
[MS-DTYP] Microsoft Corporation, "Windows Data Types".
[MS-ERREF] Microsoft Corporation, "Windows Error Codes".
[MS-NTHT] Microsoft Corporation, "NTLM Over HTTP Protocol".
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol".
[RFC1510] Kohl, J., and Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993,
[RFC1738] Berners-Lee, T., Masinter, L., and McCahill, M., Eds., "Uniform Resource Locators (URL)", RFC 1738, December 1994,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
[RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998,
[RFC2616] Fielding, R., Gettys, J., Mogul, J., et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999,
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
[RFC4559] Jaganathan, K., Zhu, L., and Brezak, J., "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006,
1.2.2Informative References
None.
1.3Overview
The Background Intelligent Transfer Service (BITS) Upload Protocol, hereafter called the BITS Upload Protocol, defines a way to transfer large payloads from a client to an HTTP server or vice versa, even in the face of interruptions, by sending the payload in multiple fragments. Both HTTP and HTTPS are supported.
The protocol allows a client to pause, resume, or cancel a transfer.
A client can also limit the rate of bandwidth used by manipulating the length and pace of the transmitted fragments; details are beyond the scope of this specification.
The protocol defines a method for the server to send a notification to a server application about the availability of a payload upon completion of the upload and to send the response data from the server application to the client.
A download from the server to the client follows standard HTTP GET syntax, using byte ranges to control the length of downloaded fragments. The message flow is summarized below:
- The client optionally determines the length of the content using a HEAD request.
- The client downloads the content by sending one or more GET requests. If the request does not encompass the entire URL, the GET request identifies the requested fragment using the Range: header.
An upload from client to server uses the message flow below.
Figure 1: Various messages exchanged among the roles as part of the protocol
In the preceding diagram, the dotted lines indicate messages that are sent only in some variations of the protocol. The following sections describe the message flow for each type of upload, and the examples in section 4 contain detailed examples of each of the messages.
Uploads can be accomplished in two modes: upload and upload-reply. The details about the messages exchanged in each mode are mentioned later.
1.3.1Message Flow Common to Both Modes
The following steps describe the message flow process that is common to both modes of operation.
- The client gets the request entity and the destination URL through the higher-layer protocol.
- The client initiates the upload by sending a CREATE-SESSION(section2.2.2) message, which prompts the server to create a BITS session for the destination URL.
- After the BITS session is created, the server sends a BITS session ID through an Ack response(section2.2.3).
- After the client determines that the BITS session creation was successful, it sends the request entity in a set of FRAGMENT(section2.2.6) messages to the server. For each fragment being sent from the client, the server processes and updates its copy of the request entity.
- After the FRAGMENT(section2.2.6) is successfully received and processed, the server sends Ack(section2.2.7) with the byte range received.
1.3.2Message Flow for Upload Mode
In this mode, the request entity is uploaded to the server. Figure 1(section1.3) explains this mode of operation in detail.
- Steps 1 through 5, described in section 1.3.1, are executed.
- After the final FRAGMENT message is processed successfully by the server, the request entity is reassembled at the server. Depending on the notification options(section3.2.1.1) (NotificationType and NotificationURL) defined on the back-end client, the back-end client can send the request entity to the server application provided through the notificationURL. This step is needed ONLY if the back-end server needs to be notified about the request entity and is not necessary for a simple upload.
- After the server sends a success Ack response to the final FRAGMENT message, the client sends a CLOSE-SESSION(section2.2.8) message, which prompts the server to move the request entity to the destination URL and delete BITS session data for the given session on the server.
1.3.3Message Flow for Upload-Reply Mode
In this mode, the server sends the request entity to the server application, which constructs a response entity. The server application sends the URL of the reply to the client as part of the response to the final FRAGMENT sent from the client. The following steps, along with the diagram in section 1.3, explain this mode of operation in detail.