Share via


Replication and the GET Method

Topic Last Modified: 2006-06-12

The GET method is used to fetch the contents of an existing resource. The GET method in the context of WebDAV replication is used to download the content change for a particular resource. The server returns the updated resourcetag of the resource in the response headers.

Normal GET method

If the client issues a GET method request without any headers specific to replication, the request will have the default behavior as defined in HTTP/1.1 and WebDAV protocol, except that the server will return the resourcetag of the affected resource.

GET method with version checking

Usually, the client wants to verify that the correct version of a resource is being fetched. If the client has previously downloaded content or properties of a resource, the server returned the resourcetag of that particular resource. Under these circumstances, the client can include the resourcetag in the request If Header of a GET method in the form of:

If: (<resourcetag>) or If: (<repl-uid>)

The If: (<resourcetag>) or If: (<repl-uid>) condition will evaluate to FALSE, thus cancelling the fetch, if the specified resourcetag or the repl-uid doesn't match the resourcetag or the repl-uid of the resource.

GET method with client-initiated conflict detection

The client should include the If: (<resourcetag>) or If: (<repl-uid>) request header in the GET method request. The resource on the server will only be fetched if the version matches. If the condition fails, the server returns a 412 Precondition Failed error code.

GET method and enforcing resource integrity

Consider the following scenario:

Client 1 downloads a resource item.eml from a particular collection called docs. Assume that the URL of the resource is http://example.org/public/docs/item.eml.

Client 1 goes offline. In the meantime, Client 2 deletes and then re-creates the resource item.eml on the server. Now Client 1 comes online and downloads the resource item.eml.

This specific scenario may or may not be an error, depending on what the client intended in the first place. If the client intended to download the contents of the resource item.eml no matter what, this is not an error. If the client's intention was to update the contents of the resource item.eml only if it is the same resource it previously downloaded, there is a problem.

One way to resolve this problem is to include the If: (<resourcetag >) or If: (<repl-uid>) condition in the request header to make sure that the client is fetching the correct version of a resource. Including the If: (<resourcetag >) condition may only partially solve the problem because although the resourcetag value is universally unique, it is not enough to distinguish between an updated version of an existing resource and updated version of a new resource with exact same URL.

This specific problem can be only resolved using the repl-uid Field on the resource, which uniquely identifies a resource. Thus, in this scenario, deleting resource item.eml and re-creating resource item.eml in the same collection will result in two different repl-uids. In effect, including both the conditions of resourcetag and repl-uid

If: (<resourcetag>) (<repl-uid>)

can solve this problem without ambiguity.