合并段
功能介绍
如果用户上传完所有的段，就可以调用合并段接口，系统将在服务端将用户指定的段合并成一个完整的对象。在执行“合并段”操作以前，用户不能下载已经上传的数据。在合并段时需要将多段上传任务初始化时记录的附加消息头信息拷贝到对象元数据中，其处理过程和普通上传对象带这些消息头的处理过程相同。在并发合并段的情况下，仍然遵循Last Write Win策略，但“Last Write”的时间定义为段任务的初始化时间。
已经上传的段，只要没有取消对应的多段上传任务，都要占用用户的容量配额；对应的多段上传任务“合并段”操作完成后，只有指定的多段数据占用容量配额，用户上传的其他此多段任务对应的段数据如果没有包含在“合并段”操作制定的段列表中，“合并段”完成后删除多余的段数据，且同时释放容量配额。
合并完成的多段上传数据可以通过已有的下载对象接口，下载整个多段上传对象或者指定Range下载整个多段上传对象的某部分数据。
合并完成的多段上传数据可以通过已有的删除对象接口，删除整个多段上传对象的所有分段数据，删除后不可恢复。
合并完成的多段上传数据不记录整个对象的MD5作为Etag，在下载多段数据或List桶内对象看到的多段数据其Etag的生成方式为：MD5（M1M2……MN）-N，其中，Mn表示第n段的MD5值， 如请求示例所示，有3个分段，每个分段都有对应的MD5值，合并段ETag的生成是先将3个分段的MD5合并起来再进行MD5计算得到一个新值，再拼接-N作为合并段的ETag值，-N表示总共有多少段，在该示例中即为-3。
合并段请求如果出现等待响应超时、服务端返回500或503报错时，建议客户端可以先尝试获取多段任务对应的对象元数据，并比较响应的x-obs-uploadId头域的值，是否与本次要合并的段任务ID相同，如果相同，说明服务端实际已经合并段成功，无需再进行重试。关于并发一致性说明，参见7.5-并发一致性说明。
多版本
如果桶的多版本状态是开启的，则合并段后得到的对象生成一个唯一的版本号，并且会在响应报头x-obs-version-id返回该版本号。如果桶的多版本状态是暂停的，则合并段后得到的对象版本号为null。关于桶的多版本状态，参见设置桶的多版本状态。
如果上传了10个段，但合并时只选择了9个段进行合并，那么未被合并的段将会被系统自动删除，未被合并的段删除后不能恢复。在进行合并之前请使用列出已上传的段接口进行查询，仔细核对所有段，确保没有段被遗漏。
请求消息样式
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
POST /ObjectName?uploadId=uploadID HTTP/1.1 Host: bucketname.obs.region.example.com Date: date Content-Length: length Authorization: authorization <CompleteMultipartUpload> <Part> <PartNumber>partNum</PartNumber> <ETag>etag</ETag> </Part> <Part> <PartNumber>partNum</PartNumber> <ETag>etag</ETag> </Part> <Part> <PartNumber>partNum</PartNumber> <ETag>etag</ETag> </Part> </CompleteMultipartUpload> |
请求消息参数
该请求在消息参数中指定多段上传任务号来标明它要合并哪一个上传段任务，参数意义如表1所示。
请求消息头
该请求使用公共消息头，具体请参考表3。
请求消息元素
该请求需要在消息中带消息元素，指定要合并的段列表，元素的具体意义如表2中所示
响应消息样式
1 2 3 4 5 6 7 8 9 |
HTTP/1.1 status_code Date: date <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <CompleteMultipartUploadResult xmlns="http://obs.region.example.com/doc/2015-06-30/"> <Location>http://example-Bucket.obs.region.example.com/example-Object</Location> <Bucket>bucketname</Bucket> <Key>ObjectName</Key> <ETag>ETag</ETag> </CompleteMultipartUploadResult> |
响应消息元素
该请求的响应消息中通过返回消息元素来返回合并段的结果，元素的具体意义如表4所示。
错误响应消息
- 如果没有消息体，OBS返回400 Bad Request。
- 如果消息体格式不正确，OBS返回400 Bad Request。
- 消息体中如果段信息未按照段序号升序排列，OBS返回400 Bad Request，错误码为InvalidPartOrder。
- 如果AccessKey或签名无效，OBS返回403 Forbidden， 错误码为AccessDenied。
- 如果请求的桶不存在，OBS返回404 Not Found，错误码为NoSuchBucket。
- 如果请求的多段上传任务不存在，OBS返回404 Not Found，包含错误信息NoSuchUpload。
- 如果用户不是该任务的发起者（initiator），OBS返回403 Forbidden，错误码为AccessDenied。
- 在合并段时如果请求段列表中包含了不存在的段，OBS返回400 Bad Request，错误码为InvalidPart。
- 如果请求段列表中包含的段的Etag错误，OBS返回400 Bad Request，错误码为InvalidPart。
- 除最后一个段之外的其它段尺寸过小（小于100KB），OBS返回400 Bad Request。
- 对象在合并完成后总大小如果超过48.8TB，OBS返回400 Bad Request。
其他错误已包含在表2中。
请求示例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
POST /object02?uploadId=00000163D46218698DF407362295674C HTTP/1.1 User-Agent: curl/7.29.0 Host: examplebucket.obs.region.example.com Accept: */* Date: WED, 01 Jul 2015 05:23:46 GMT Authorization: OBS H4IPJX0TQTHTHEBQQCEC:dOfK9iILcKxo58tRp3fWeDoYzKA= Content-Length: 422 <?xml version="1.0" encoding="utf-8"?> <CompleteMultipartUpload> <Part> <PartNumber>1</PartNumber> <ETag>a54357aff0632cce46d942af68356b38</ETag> </Part> <Part> <PartNumber>2</PartNumber> <ETag>0c78aef83f66abc1fa1e8477f296d394</ETag> </Part> <Part> <PartNumber>3</PartNumber> <ETag>acbd18db4cc2f85cedef654fccc4a4d8</ETag> </Part> </CompleteMultipartUpload> |
响应示例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
HTTP/1.1 200 OK Server: OBS x-obs-request-id: 8DF400000163D4625BE3075019BD02B8 x-obs-id-2: 32AAAQAAEAABAAAQAAEAABAAAQAAEAABCSN8D1AfQcIvyGBZ9+Ee+jU6zv1iYdO4 Content-Type: application/xml Date: WED, 01 Jul 2015 05:23:46 GMT Content-Length: 326 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <CompleteMultipartUploadResult xmlns="http://obs.example.com/doc/2015-06-30/"> <Location>/examplebucket/object02</Location> <Bucket>examplebucket</Bucket> <Key>object02</Key> <ETag>"03f814825e5a691489b947a2e120b2d3-3"</ETag> </CompleteMultipartUploadResult> |
