Comment 2 for bug 1467668

This sort of thing seems to come down to a distinct choice of what we want to provide to users.

On the one hand, as Sam mentions, current behavior is exactly as if you had streamed the requests locally to create the new "copy" of the object. So it makes sense when you think about it, but it doesn't really provide any sort of new functionality for users. Who wants a multipart MIME document as the contents of an object?

On the other, single range copies already end up with creating a new object with just the subset of the object. Extending that to multi-range copies and you get something that wasn't otherwise easily possible by doing it on the client side. Copy with ranges then becomes "create this new object from these byte ranges in that other object". And that's something that is interesting, I think.

I'd lean towards the second implementation over the first.