Hi Christopher, thank you for your question. A member of the protocol documentation team will be in touch with you soon.
Josh Curry | Escalation Engineer | Open Specifications Support Team P +1 469 775 7215 One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com -----Original Message----- From: Christopher R. Hertel [mailto:[email protected]] Sent: Wednesday, February 22, 2012 2:22 PM To: Interoperability Documentation Help Cc: [email protected]; [email protected] Subject: Incomplete information in [MS-PCCRC: 3.1, 3.2] Dear Dochelp, Referencing the version of [MS-PCCRC] with the release data of Wednesday, December 14, 2011 (marked "Preliminary"). Section 3.1 has the following text: Scenario: A server S wants clients to use the Content Caching and Retrieval Framework to accelerate content distribution for a 125 kilobyte (KB) file. The server is configured to use SHA-256 as the hash algorithm and uses a secret value which is the ASCII string "no more secrets". A client requests the entirety of the 125 kilobyte content from the server. The server responds with Content Information of the following form. It then shows the expected response from the server, in table form. The value of dwReadBytesInLastSegment is given as 128000. ...but that's not actually what Windows2008r2 returns. If the entire file is requested, with no "Range:" header field specified in the HTTP1.1 headers, the W2K8r2 IIS server returns 0 (zero) in the dwReadBytesInLastSegment field, not 128000. This can be seen in the output shown below: PeerDist Version...........: 1.0 (Version = 0x0100) Hash Algorithm.............: SHA-256 (dwHashAlgo = 0x0000800c) Offset into First Segment..: 0 (dwOffsetInFirstSegment = 0x00000000) Range bytes in Last Segment: 0 (dwReadBytesInLastSegment = 0x00000000) Segment count..............: 1 (cSegments = 0x00000001) Segment Descriptions (1): { Range Start..............: 0 (ullOffsetInContent = 0x0000000000000000) Length of Segment........: 128000 (cbSegment = 0x0001f400) Block Size (always 64K)..: 65536 (cbBlockSize = 0x00010000) SegmentHashOfData........: [435c9a17540b740bba3bf360040728f8b257049c1f26b8f807fa087bda2cafbd] SegmentSecret (HMAC).....: [7706c9ee034d7347b32188b7452c641b2fe293033647e729b429257415e21932] } Segment Content Blocks (1): { Block count.............: 2 (cBlocks = 0x00000002) { 000: cc1c00d40299adb1bbf834a2a5ee9408cc0cc024d6087a294df6430c217ada82 001: c436acecf8af3dde0c5d4b1741f849f0b987bdb3235476fc2491019760dda914 } } If the "Range:" header is given in the request--even if it requests the entire content of the file (the same content as the GET without "Range:"), then the response matches what is given in the documentation: PeerDist Version...........: 1.0 (Version = 0x0100) Hash Algorithm.............: SHA-256 (dwHashAlgo = 0x0000800c) Offset into First Segment..: 0 (dwOffsetInFirstSegment = 0x00000000) Range bytes in Last Segment: 128000 (dwReadBytesInLastSegment = 0x0001f400) Segment count..............: 1 (cSegments = 0x00000001) Segment Descriptions (1): { Range Start..............: 0 (ullOffsetInContent = 0x0000000000000000) Length of Segment........: 128000 (cbSegment = 0x0001f400) Block Size (always 64K)..: 65536 (cbBlockSize = 0x00010000) SegmentHashOfData........: [435c9a17540b740bba3bf360040728f8b257049c1f26b8f807fa087bda2cafbd] SegmentSecret (HMAC).....: [7706c9ee034d7347b32188b7452c641b2fe293033647e729b429257415e21932] } Segment Content Blocks (1): { Block count.............: 2 (cBlocks = 0x00000002) { 000: cc1c00d40299adb1bbf834a2a5ee9408cc0cc024d6087a294df6430c217ada82 001: c436acecf8af3dde0c5d4b1741f849f0b987bdb3235476fc2491019760dda914 } } Problems: * The current [MS-PCCRC] document only shows the behavior if the content range is explicitly given. * [MS-PCCRC] does not specify that the behavior differs if the range is not explicitly given (but Windows does behave differently in this case). * It is not clear whether this difference is a Windows Behavior (a bug) or a protocol requirement. Packet captures are available upon request (but this is easy to reproduce). I recall discussing this problem with the BranchCache team when I was in Redmond last July for an Interop Lab, so I'm a little surprised that it has not been addressed. I'll be there next week too. Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- [email protected] OnLineBook -- http://ubiqx.org/cifs/ -)----- [email protected] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
