[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] Incomplete information in [MS-PCCRC: 3.1, 3.2]
From:       Josh Curry <Josh.Curry () microsoft ! com>
Date:       2012-02-22 20:30:17
Message-ID: 09577970C9A03E44B3A7CDE646D1C8806E47E536 () TK5EX14MBXC112 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]

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:crh@ubiqx.mn.org] 
Sent: Wednesday, February 22, 2012 2:22 PM
To: Interoperability Documentation Help
Cc: cifs-protocol@samba.org; pfif@tridgell.net
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/     -)-----   crh@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org


_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread]