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
