[cifs-protocol] [REG:111061070310825] RE: [MS-PCCRC]: Handling of multi-range Range: headers is undefined.

Wed Jun 22 16:34:29 MDT 2011

Obaid,

I am not blocked, per se.

After your previous message, I have decided that I want to test sending a 
multi-part response.  I believe (though this is really a guess) that the 
reason it was not documented is that Windows clients do not send 
multi-byte range requests so the question never came up.

If that is the case, then it would be perfectly safe to send a multi-part 
response.  Only clients that could handle it would send such a request.

The multi-part response would utilize a standard feature of HTTP, which is 
the transport that would be used in this case, so there would be *no* 
change to the PeerDist 1.0 protocol.  Just a change to the document that 
would say something like...

"A server receving a PeerDist 1.0 request for multiple block ranges should 
respond by sending an HTTP multi-part response."

...or somesuch.

Chris -)-----

On Wed, Jun 22, 2011 at 10:02:55PM +0000, Obaid Farooqi wrote:
> Hi Chris:
> The product group is looking at the wording you provided.
> I want to make sure you are unblocked after my previous response. Please let me know.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at allisong at microsoft.com
> 
> -----Original Message-----
> From: Christopher R. Hertel [mailto:crh at ubiqx.mn.org]
> Sent: Tuesday, June 21, 2011 8:59 PM
> To: Obaid Farooqi
> Cc: team at ubiqx.com; MSSolve Case Email; cifs-protocol at samba.org
> Subject: Re: [cifs-protocol] [REG:111061070310825] RE: [MS-PCCRC]: Handling of multi-range Range: headers is undefined.
> 
> Obaid,
> 
> I have a concern about the wording of the sample text your team provided.
> 
> It is not necessary for the Branchcache content information format to support multi-range requests.  The response to a multi-range request could clearly be sent as separate content information messages in a multi-part HTTP response.  That type of response would be the correct response from an HTTP server.  In fact, the actual content is sent as a multi-part HTTP response if a multi-range request is sent.
> 
> As far as I can tell, there is no reason that the server could not response with a multi-part response *except* that current implementations do not know how to handle multi-part responses containing Content Information.  (I have not actually tested this, ...maybe they *can* handle multi-part responses and no one knows.)
> 
> So, I believe that the proper statement would be:
> 
> "Clients implementing the PeerDist 1.0 protocol MUST NOT send requests for multiple byte ranges if peerdist encoding is being requested in the Accepted-Encoding header.  Servers inplementing the PeerDist 1.0 protocol MUST NOT return Content Information in response to a request for multiple byte ranges of content."
> 
> Please let me know what you think about my perspective on this.
> 
> Thanks!
> 
> Chris -)-----
> 
> On Tue, Jun 21, 2011 at 11:42:51PM +0000, Obaid Farooqi wrote:
> > 
> > Hi Chris:
> > We have finished our investigation on your question regarding the response to a multi-range request.
> > 
> > I discussed the issue with product group and here is what they think is the proper answer. 
> > 
> > "The BranchCache content information format does not support multi-range requests therefore PeerDist 1.0 capable servers cannot send PeerDist Content Information in response to a request for multiple ranges."
> > 
> > MS-PCCRTP will be modified along the lines of the above statement and I'll let you know when the exact verbiage is available.
> > 
> > Please let me know if it answers your question. If it does, I'll consider this issue resolved.
> > 
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> > 
> > Exceeding your expectations is my highest priority.  If you would like 
> > to provide feedback on your case you may contact my manager at 
> > allisong at microsoft.com
> > 
> > -----Original Message-----
> > From: ubiqx Consulting, Inc. [mailto:team at ubiqx.com]
> > Sent: Friday, June 10, 2011 1:28 PM
> > To: Interoperability Documentation Help
> > Cc: cifs-protocol at samba.org
> > Subject: [MS-PCCRC]: Handling of multi-range Range: headers is undefined.
> > 
> > RFC 2616 defines the format for the Range: header in such a way as to allow multiple ranges to be specified in a single header line.  An example given in [RFC2616, section 14.35.1] is as follows:
> > 
> >   - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1
> > 
> > When I send a multiple byte range request, such as the following, to an IIS server running on Windows 2008R2 with BranchCache PeerDist enabled, I do not receive a PeerDist response (even though I know that the PeerDist Content Information has been calculated).
> > 
> >   Range: bytes=1024-66559,-67890
> > 
> > Instead, I receive a (perfectly legal) standard multipart response.
> > 
> > There really is nothing wrong with the response.  The server has the option of choosing not to send a PeerDist-encoded response.  However, [MS-PCCRC] and [MS-PCCRTP] do not provide any guidance on the following topics:
> > 
> >  * Are multi-range requests supported at all by PeerDist 1.0?
> > 
> >  * If not, "SHOULD" the server simply ignore the "peerdist" option in the
> >    Accept_Encoding header?
> > 
> >  * If multi-range requests are supported, how should the multiple PeerDist
> >    Content Information blocks be presented to the client?
> > 
> > I imagine one of two answers.  Either:
> > * PeerDist 1.0 capable servers MUST NOT send PeerDist Content
> >   Information in response to a request for multiple ranges,
> > *or*
> > * The HTTP1.1 response should be multipart (multipart/byteranges?) and
> >   each PeerDist range should be contained within a boundary.
> > 
> > I suppose that the answer will depend upon what the current Windows clients can accept.
> > 
> > Please let me know how PeerDist 1.0 MUST/SHOULD/MAY handle multi-range requests.
> > 
> > Thanks.
> > 
> > Chris -)-----
> > 
> > -- 
> > http://www.ubiqx.com/               Data Storage and Systems Consulting
> > 
> > _______________________________________________
> > cifs-protocol mailing list
> > cifs-protocol at cifs.org
> > https://lists.samba.org/mailman/listinfo/cifs-protocol
> 
> Microsoft is committed to protecting your privacy.  Please read the Microsoft Privacy Statement for more information.The above is an email for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE casemail at microsoft.com IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you.