Multi Range Read with with server side copy results in a MIME

[Douglas Soltesz]

When using a Multiple range reads against an object a Multipart MIME is returned as per HTTP 1.1 RFC 7233 https://tools.ietf.org/html/rfc7233#appendix-A.

However, when the multiple range read is used in conjunction with Server Side Copy, the resulting object should be the concatenation of the data ranges. What is stored is a MIME.

Example:

curl -i -X PUT -H "$token" $surl/RRead/mybook --data-binary 'It was the best of times, it was the worst of times'
HTTP/1.1 201 Created

curl -i -X COPY -H "$token" -H "Range: bytes=7-15,46-49" -H "Destination: RRead/mybook-short" $surl/RRead/mybook
< HTTP/1.1 201 Created
< Content-Length: 0
< X-Copied-From-Last-Modified: Mon, 22 Jun 2015 20:44:22 GMT
< X-Copied-From: RRead/mybook
< Last-Modified: Mon, 22 Jun 2015 20:45:05 GMT
< Etag: 76c65485acf2caae98cf3afcdc5ad106
< X-Copied-From-Account: AUTH_swiftstack
< Content-Type: text/html; charset=UTF-8
< X-Trans-Id: txb68736b4f7f7460392ed6-00558873d0
< Date: Mon, 22 Jun 2015 20:45:04 GMT
curl -i -X GET -H "$token" $surl/RRead/mybook-short
HTTP/1.1 200 OK
Content-Length: 292
Accept-Ranges: bytes
Last-Modified: Mon, 22 Jun 2015 20:45:05 GMT
Etag: 76c65485acf2caae98cf3afcdc5ad106
X-Timestamp: 1435005904.55136
Content-Type: multipart/byteranges;boundary=df49a0fa41ff5f33d6a61475b0d9a4bd
X-Trans-Id: tx58f5f380b3764cd181151-0055887454
Date: Mon, 22 Jun 2015 20:47:16 GMT

--df49a0fa41ff5f33d6a61475b0d9a4bd
Content-Type: application/x-www-form-urlencoded
Content-Range: bytes 7-15/51

the best
--df49a0fa41ff5f33d6a61475b0d9a4bd
Content-Type: application/x-www-form-urlencoded
Content-Range: bytes 46-49/51

time
--df49a0fa41ff5f33d6a61475b0d9a4bd--

Expected result was "the besttime"

[Samuel Merritt (torgomatic)]

I'm not convinced it's better. Imagine that you make GET and PUT requests, and plumb the output of the GET into the input of the PUT; you'd end up creating some object. COPY is like doing that, but without the requirement that you move all the bytes across the cluster boundary twice.

If you did the PUT+GET with multiple byteranges on the GET, you'd end up with an object whose contents are a MIME document. The fact that COPY does this already seems exactly right.

[John Dickinson (notmyname)]

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.

[Samuel Merritt (torgomatic)]

So here's an edge case to consider: multiple byte ranges requested, but only some satisfiable. With the MIME doc, you know what bytes are what. With concatenation, you requested, say, 7 MB total, but you only got 5 MB. Which bytes are they?

[John Dickinson (notmyname)]

This is related to https://bugs.launchpad.net/swift/+bug/1521359 (although not a duplicate)