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 > [email protected] > > -----Original Message----- > From: Christopher R. Hertel [mailto:[email protected]] > Sent: Tuesday, June 21, 2011 8:59 PM > To: Obaid Farooqi > Cc: [email protected]; MSSolve Case Email; [email protected] > 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 > > [email protected] > > > > -----Original Message----- > > From: ubiqx Consulting, Inc. [mailto:[email protected]] > > Sent: Friday, June 10, 2011 1:28 PM > > To: Interoperability Documentation Help > > Cc: [email protected] > > 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 > > [email protected] > > 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 > [email protected] 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. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
