- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 24 Mar 1997 23:54:20 -0800
- To: DAV Discussion <davdisc@microsoft.com>
1 Merge Header 1.1 Problem Definition There is currently no mechanism for the user to inform the server that the entity they are PUTing is the result of a merge between a number of other resources. 1.2 Proposal I propose introducing a new header called merge. MergeHeader = "Merge" ":" #(URI [SP entity-tag]) The Merge header lists the resources that have been merged in order to form the entity that is to be PUT. Note that the entity in question may either be in the request body of the PUT or referred to by the Source header. The entity tags are used to provide a more accurate specification of exactly what was merged. The entity tags are optional because servers are not required to return entity tags. 1.3 Example The client performs: GET http://foo HTTP/1.1 In the response the client receives the e-tag "1234". The client then performs: GET http://bar HTTP/1.1 In the response the client receives the e-tag "1234" The client then merges the two entities and performs: PUT http://foo HTTP/1.1 Merge: http://foo "1234", http://bar "1234" <Response Body> The client has informed the server that the PUT contains an entity which is the merge of http://foo in state "1234" and http://bar in state "1234". Note, the fact that the two e-tags are identical is irrelevant. An e-tag is only defined in the scope of its associated URI. 1.4 Structure Behavior Please see the upcoming position paper on structures and the PUT method. However, what I will basically be saying is, a structure is a resource. There is nothing special about it, other than it happens to respond to the STRUCTURE method. 2 Merge Attribute 2.1 Problem Definition A client can find out that a resource requires a merge header on a PUT by PUTting a result and then receiving a 409 "Conflict" response. However this is an expensive way to find out about the merge requirement. Especially as the current HTTP 1.1 specification has a SHOULD level requirement that the server return a difference of the PUT body and the current resource state. A cheaper mechanism to determine when a Merge is required is needed. 2.2 Proposal I propose defining the DAV:MERGE attribute which is a read only attribute that returns a value with the following syntax: DAVMERGEResult = "Yes" | "No" | "Not_Supported" | Token "Yes" means that a PUT will only be accepted if it contains a merge header which itself contains the URI and entity tag for the resource the DAV:MERGE has been defined on. "No" means that a merge header is not required but the server is able to record the merge header. "Not_Supported" means that the server does not support the merge header and will drop it from requests on this resource. 2.3 Discussion It is not my expectation that before every PUT a client will be required to check DAV:MERGE. I suspect that context will let a client know when a merge is likely to be necessary. For example, if the user is manipulating versioned resource, merges will most likely be necessary.
Received on Tuesday, 25 March 1997 06:38:44 UTC