Client Needs to Fetch a Manifest
Topic Last Modified: 2006-06-12
The client can use the SEARCH Method to fetch the manifest of a collection has never been previously fetched from the server. 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 collblob XML Element and collblob to request the manifest of the collection.
- The sql XML element to specify the criteria that the server will evaluate to provide the appropriate manifest. Note that the query specified in the sql XML element will be associated by the server with the collblob and hence cannot be changed for the lifetime of the collblob except for the columns or properties list. In the example below, the client is interested in synchronizing just three properties of all the resources in the collection 'Inbox'.
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/>
</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>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/msg4</D:href>
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:Size>14400</D:Size>
<M:Importance>High</M:Importance>
<R:resourcetag>doc2-02</R:resourcetag>
</D:prop>
</D:propstat>
<R:changetype>change</R:changetype>
</D:response>
</D:multistatus>