Comment 2 for bug 1487791

So what *should* happen with a POST? (regardless of object_post_as_copy value - the outcome should be the same either way for a consistent API behaviour)

First, should a POST ever result in the DLO segments being "squashed" into what was the manifest object? IMHO, no - with post-as-copy that may result in errors when size of large object is > 5GB as reported.

Second, how should the presence or not of x-object-manifest header in the POST request be handled? I can see three options for the desired outcomes:

1) existing x-object-manifest value is *always preserved* on POST i.e. any x-object-manifest header sent with a POST is ignored, the original PUT x-object-manifest value can only be changed by another PUT.

2) existing x-object-manifest value is *always updated* with the value supplied with POST, and if POST has no x-object-manifest then the outcome is an object with no x-object-manifest value. i.e. client must provide x-object-manifest value with every POST in order to preserve the manifest property of the object.

3) existing x-object-manifest value is updated IF a new value is provided in the POST, otherwise the existing value is preserved. I strongly dislike this outcome because it is very hard to implement with object_post_as_copy=False (fast-POST). With fast-post it requires the object servers to maintain the timestamp of X-Object-Manifest values independently of the data or metadata timestamps in order to reconcile X-Object-Manifest values between replicas that may have become inconsistent. This is exactly the same problem that [1] is fixing with content-type, and it is non-trivial. So if we choose this option for post-as-copy we are adding significant pain to getting fast-post to provide the same behaviour.

So for me its between 1 and 2. Any other opinions?

[1] https://review.openstack.org/135380