Proposal for Merge Header and Attribute

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