Multi Range Read with with server side copy results in a MIME
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
When using a Multiple range reads against an object a Multipart MIME is returned as per HTTP 1.1 RFC 7233 https:/
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-
< X-Copied-From: RRead/mybook
< Last-Modified: Mon, 22 Jun 2015 20:45:05 GMT
< Etag: 76c65485acf2caa
< X-Copied-
< Content-Type: text/html; charset=UTF-8
< X-Trans-Id: txb68736b4f7f74
< Date: Mon, 22 Jun 2015 20:45:04 GMT
curl -i -X GET -H "$token" $surl/RRead/
HTTP/1.1 200 OK
Content-Length: 292
Accept-Ranges: bytes
Last-Modified: Mon, 22 Jun 2015 20:45:05 GMT
Etag: 76c65485acf2caa
X-Timestamp: 1435005904.55136
Content-Type: multipart/
X-Trans-Id: tx58f5f380b3764
Date: Mon, 22 Jun 2015 20:47:16 GMT
--df49a0fa41ff5
Content-Type: application/
Content-Range: bytes 7-15/51
the best
--df49a0fa41ff5
Content-Type: application/
Content-Range: bytes 46-49/51
time
--df49a0fa41ff5
Expected result was "the besttime"
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.