Client Has Processed Some Items and Needs an Updated Manifest
Topic Last Modified: 2006-06-12
Assume that the client has synchronized with a collection, obtained a collblob, and processed some items out-of-band. The client then wants to fetch the updated manifest and collblob for the collection. One example of out-of-band fetching is when the client downloads a few resources from a collection and then wants to synchronize the contents of the collection. In this case, the client has the resourcetags that represent the states of the downloaded resources and now wants to request that the server include those changes in the collblob. Before sending the SEARCH Method request, the following must be added to the request XML body:
- The searchrequest XML element.
- The repl XML Element as a child of the searchrequest XML element.
- The previously obtained collblob for the collection in collblob XML Element in order to request the updated manifest.
- The list of resourcetags obtained out-of-band as children of the resourcetaglist XML Element.
The server provides the following in the SEARCH Method response XML body:
- A multistatus XML Element.
- A repl XML Element.
- A collblob XML Element as a child node of the repl XML Element. The collblob XML Element includes the opaque collblob binary stream. When the server builds the collblob, the server assumes that the client has seen all the changes listed in this manifest response. The server associates the Structured Query Language (SQL)SELECT Statement provided in the SEARCH Method request with the collblob.
For each change that matches the criteria given by the client in the SEARCH Method request, the server includes the change in a response XML Element. The response XML Element includes:
- An href XML Element that identifies the resource.
- An prop XML Element that includes the properties that the client requested.
- An changetype XML Element that specifies the changetype: "change" or "delete". The default changetype is "change" and, if the changetype XML Element is absent from the response XML Element, the client should assume that the changetype is "change".
Request
SEARCH /exchange/user0/inbox HTTP/1.1
Host: example.com
Content-type: text/xml
Content-length: {insert length here}
<?xml version="1.0"?>
<D:searchrequest xmlns:D="DAV:" xmlns:R="https://schemas.microsoft.com/repl/"
xmlns:M="urn:schemas:mail:">
<R:repl>
<R:collblob>clientopaquedata</R:collblob>
<R:resourcetaglist>
<R:resourcetag>rt:doc1-06</R:resourcetag>
<R:resourcetag>rt:doc2-03</R:resourcetag>
<R:resourcetag>rt:doc3-09</R:resourcetag>
</R:resourcetaglist>
</R:repl>
<D:sql>SELECT 'urn:schemas:mail:Size', 'urn:schemas:mail:Importance',
'https://schemas.microsoft.com/repl/resourcetag'
FROM SCOPE ('SHALLOW TRAVERSAL OF "/exchange/user0/inbox"')
</D:sql>
</D:searchrequest>
Response
HTTP/1.1 207 Multi-Status
Content-type: text/xml
Content-length: {insert length here}
<?xml version="1.0"?>
<D:multistatus xmlns:D="DAV:" xmlns:R="https://schemas.microsoft.com/repl/"
xmlns:M="urn:schemas:mail:">
<R:repl>
<R:collblob>clientopaquedata</R:collblob>
</R:repl>
<D:response>
<D:href>http://example.org/exchange/user0/inbox/msg1</D:href>
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:Size>1000</D:Size>
<M:Importance>High</M:Importance>
<R:resourcetag>rt:doc1-01</R:resourcetag>
</D:prop>
</D:propstat>
<R:changetype>change</R:changetype>
</D:response>
<D:response>
<D:href> http://example.org/exchange/user0/inbox</D:href>
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<R:resourcetag>rt:doc1-01</R:resourcetag>
<R:repl-uid>rid:19a23000c26511d18faf04440892444c</R:repl-uid>
</D:prop>
</D:propstat>
<R:changetype>delete</R:changetype>
</D:response>
</D:multistatus>