7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

• Windows Vista operating system

• Windows Server 2008 operating system

• Windows 7 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3: The MS-BPCR protocol is supported only in BITS version 3.0. BITS version 4.0 replaces the BITS Peercaching protocols with the Branch Cache protocol family. See [MS-CCROD] for details of BITS integration with Branch Cache protocols.

<2> Section 1.3.1: In Windows 7, the BITS 3.0 peer caching model is deprecated. If BITS 4.0 is installed, the BITS 3.0 peer caching model is unavailable. If BITS 4.0 is installed, peer caching now uses Windows BranchCache as described in [MS-CCROD].

<3> Section 2.1: Windows verifies that the received certificate is self-signed and is present in the "BITS\Peers" substore of the CERT_SYSTEM_STORE_SERVICES certificate store.

<4> Section 2.2.1.5: The Windows peer server never includes this element. The Windows peer client ignores this element.

<5> Section 2.2.1.6: The Windows client always sends a value of 5.

<6> Section 2.2.1.6: Windows ignores records beyond MaxRecords.

<7> Section 2.2.2.2: Windows sends this header in all requests. The GUID is unique among all DISCOVERY-REQUESTs sent by a particular client.

<8> Section 2.2.2.3: Windows ignores attributes in XML elements.

<9> Section 2.2.3.2: Windows ignores attributes in XML elements.

<10> Section 2.2.3.2: Windows includes one comment in both success and failure responses; the comment contains the HRESULT of the internal operation in the following format:

 4*SP "<!-- Error 0x" HR " -->" CRLF

<11> Section 2.2.4: The BITS component of Windows Vista uses HTTP ranges to resume an interrupted download, and it also uses ranges for rate control when a "background" download is requested.

<12> Section 2.2.5: Windows always provides this header.

<13> Section 2.2.6: The Windows client sends HEAD requests in some circumstances. Specifically, it sends a HEAD prior to downloading when the priority of the client's BITS job is not bg_job_priority_foreground, and it omits the HEAD when the priority is bg_job_priority_foreground. For an overview of BITS in Windows, see [MSDN-BITS].

<14> Section 3.1.2.3: Windows uses a value of five minutes.

<15> Section 3.1.7.1.1: Windows attempts to authenticate the server by an exchange of certificates via the BITS Peer-Caching: Peer Authentication Protocol (for more details, see [MS-BPAU]).

<16> Section 3.1.7.2.1: Windows verifies that the received certificate is self-signed and is present in the "BITS\Peers" substore of the CERT_SYSTEM_STORE_SERVICES certificate store.

<17> Section 3.1.7.3.1: Windows removes peers from the table after transport errors.

<18> Section 3.1.7.3.4: Windows attempts to authenticate the client by an exchange of certificates via the BITS Peer-Caching: Peer Authentication Protocol (for more details, see [MS-BPAU]).

<19> Section 3.1.7.3.6: Windows attempts to authenticate the server by an exchange of certificates via the BITS Peer-Caching: Peer Authentication Protocol (for more details, see [MS-BPAU]).

<20> Section 3.2.5.1: Windows responses contain an empty entity body except in a small number of cases. A response with HTTP status 411 contains HTML declaring that a request is required to contain a content length or be in chunked format. A response triggered by failure in validation of the client's certificate contains an entity body in Unicode with the following ABNF structure (as defined in [RFC5234]):

 quot = %d34
 HR = 8*HEXDIG
 Body = "<?xml version=" quot "1.0" quot " encoding=" quot "utf-16" quot "?>" CRLF
 "<SearchResults>" CRLF
 4*SP "<!-- Error 0x" HR " -->" CRLF
 4*SP "<Status>" quot RESULT quot "</Status>" CRLF
 "</SearchResults>" CRLF
  

The value of the HR rule in the ABNF represents the internal HRESULT value generated by the server operation that failed. The generated RESULT values are listed in the following table.

<21> Section 3.2.5.2: Windows allows only three messages to be processed simultaneously.

<22> Section 3.2.5.3: Windows limits the size of the HTTP header fields to 16 kilobytes, and limits the XML body to 1 megabyte.

<23> Section 3.2.5.3: Windows includes an embedded XML comment specifying an HRESULT status, unless the <Status> element is "Success" or "ContentNotFound". If an error occurs during parsing of the client request, the HRESULT value of the error appears here. The HRESULT is not consumed by the Windows client; it was included only for debugging purposes. The ABNF form of a failure reply, including the comment, is the same as in note <28>.

The value of the <Status> element depends on the parsing error as well, and is specified by the following table.

<24> Section 3.2.5.4: Windows returns status 206 when the request contains a Content-Range header, even when the range covers the entire record.