Client Needs to Fetch an Updated Manifest

Client Needs to Fetch an Updated Manifest

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release. The client can use the SEARCH Method to fetch the manifest of a collection that has 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 previously obtained collblob for the collection in collblob XML Element to request the updated manifest.
• 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 must be the exact same query as specified in the original query when the collblob was first obtained. The client can specify a different set of properties to fetch, however.

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: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-04</R:resourcetag>
         </D:prop>
      </D:propstat>
   </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:doc2-03</R:resourcetag>
            <R:repl-uid>rid:19a23000c26511d18faf04440892444c</R:repl-uid>
         </D:prop>
      </D:propstat>
      <R:changetype>delete</R:changetype>
   </D:response>
</D:multistatus>

Related Topics

• Fetching an Updated Manifest

Send us your feedback about the Microsoft Exchange Server 2003 SDK.

This topic last updated: December 2004

Build: June 2007 (2007.618.1)

© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.