全部产品
对象存储 OSS

AppendObject

更新时间:2017-06-07 13:26:11   分享:   

Append Object

Append Object以追加写的方式上传文件。通过Append Object操作创建的Object类型为Appendable Object,而通过Put Object上传的Object是Normal Object。

请求语法

  1. POST /ObjectName?append&position=Position HTTP/1.1
  2. Content-LengthContentLength
  3. Content-Type: ContentType
  4. Host: BucketName.oss.aliyuncs.com
  5. Date: GMT Date
  6. Authorization: SignatureValue

请求Header

名称 描述
Cache-Control 指定该Object被下载时的网页的缓存行为;更详细描述请参照RFC2616
类型:字符串
默认值:无
Content-Disposition 指定该Object被下载时的名称;更详细描述请参照RFC2616
类型:字符串
默认值:无
Content-Encoding 指定该Object被下载时的内容编码格式;更详细描述请参照RFC2616
类型:字符串
默认值:无
Content-MD5 根据协议RFC 1864对消息内容(不包括头部)计算MD5值获得128比特位数字,对该数字进行base64编码为一个消息的Content-MD5值。该请求头可用于消息合法性的检查(消息内容是否与发送时一致)。虽然该请求头是可选项,OSS建议用户使用该请求头进行端到端检查。
类型:字符串
默认值:无
限制:无
Expires 过期时间;更详细描述请参照RFC2616
类型:整数
默认值:无
x-oss-server-side-encryption 指定oss创建object时的服务器端加密编码算法。
类型:字符串
合法值:AES256
x-oss-object-acl 指定oss创建object时的访问权限。
类型:字符串
合法值:public-read,private,public-read-write

响应Header

名称 描述
x-oss-next-append-position 指明下一次请求应当提供的position。实际上就是当前Object长度。当Append Object成功返回,或是因position和Object长度不匹配而引起的409错误时,会包含此header。
类型:64位整型
x-oss-hash-crc64ecma 表明Object的64位CRC值。该64位CRC根据ECMA-182标准计算得出。
类型:64位整型

和其他操作的关系

  1. 不能对一个非Appendable Object进行Append Object操作。例如,已经存在一个同名Normal Object时,Append Object调用返回409,错误码ObjectNotAppendable。
  2. 对一个已经存在的Appendable Object进行Put Object操作,那么该Appendable Object会被新的Object覆盖,类型变为Normal Object。
  3. Head Object操作会返回x-oss-object-type,用于表明Object的类型。对于Appendable Object来说,该值为Appendable。对Appendable Object,Head Object也会返回上述的x-oss-next-append-position和x-oss-hash-crc64ecma。
  4. Get Bucket(List Objects)请求的响应XML中,会把Appendable Object的Type设为Appendable
  5. 可以使用Copy Object来改变它的服务器端加密的属性或是用户自定义元信息。也可以把Appendable Object拷贝成另外一个文件,新的文件也是Appendable Object。

细节分析:

  1. URL参数append和position均为CanonicalizedResource,需要包含在签名中。
  2. URL的参数必须包含append,用来指定这是一个Append Object操作。
  3. URL查询参数还必须包含position,其值指定从何处进行追加。首次追加操作的position必须为0,后续追加操作的position是Object的当前长度。例如,第一次Append Object请求指定position值为0,content-length是65536;那么,第二次Append Object需要指定position为65536。每次操作成功后,响应头部x-oss-next-append-position也会标明下一次追加的position。
  4. 如果position的值和当前Object的长度不一致,OSS会返回409错误,错误码为PositionNotEqualToLength。发生上述错误时,用户可以通过响应头部x-oss-next-append-position来得到下一次position,并再次进行请求。
  5. 当Position值为0时,如果没有同名Appendable Object,或者同名Appendable Object长度为0,该请求成功;其他情况均视为Position和Object长度不匹配的情形。
  6. 当Position值为0,且没有同名Object存在,那么Append Object可以和Put Object请求一样,设置诸如x-oss-server-side-encryption之类的请求Header。这一点和Initiate Multipart Upload是一样的。如果在Position为0的请求时,加入了正确的x-oss-server-side-encryption头,那么后续的Append Object响应头部也会包含x-oss-server-side-encryption头,其值表明加密算法。后续如果需要更改meta,可以使用Copy Object请求。
  7. 由于并发的关系,即使用户把position的值设为了x-oss-next-append-position,该请求依然可能因为PositionNotEqualToLength而失败。
  8. Append Object产生的Object长度限制和Put Object一样。
  9. 每次Append Object都会更新该Object的最后修改时间。
  10. 在position值正确的情况下,对已存在的Appendable Object追加一个长度为0的内容,该操作不会改变Object的状态。
  11. 如果Bucket的类型为Archive,则不能调用该接口,否则返回400错误,错误码为OperationNotSupported。

CRC64的计算方式

Appendable Object的CRC采用ECMA-182标准,和XZ的计算方式一样。用Boost CRC模块的方式来定义则有:

  1. typedef boost::crc_optimal<64, 0x42F0E1EBA9EA3693ULL, 0xffffffffffffffffULL, 0xffffffffffffffffULL, true, true> boost_ecma;
  2. uint64_t do_boost_crc(const char* buffer, int length)
  3. {
  4. boost_ecma crc;
  5. crc.process_bytes(buffer, length);
  6. return crc.checksum();
  7. }

或是用Python crcmod的方式为:

  1. do_crc64 = crcmod.mkCrcFun(0x142F0E1EBA9EA3693L, initCrc=0L, xorOut=0xffffffffffffffffL, rev=True)
  2. print do_crc64(“123456789”)

示例

请求示例:

  1. POST /oss.jpg?append&position=0 HTTP/1.1
  2. Host: oss-example.oss.aliyuncs.com
  3. Cache-control: no-cache
  4. Expires: Wed, 08 Jul 2015 16:57:01 GMT
  5. Content-Encoding: utf-8
  6. Content-Disposition: attachment;filename=oss_download.jpg
  7. Date: Wed, 08 Jul 2015 06:57:01 GMT
  8. Content-Type: image/jpg
  9. Content-Length: 1717
  10. Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:kZoYNv66bsmc10+dcGKw5x2PRrk=
  11. [1717 bytes of object data]

返回示例:

  1. HTTP/1.1 200 OK
  2. Date: Wed, 08 Jul 2015 06:57:01 GMT
  3. ETag: "0F7230CAA4BE94CCBDC99C5500000000"
  4. Connection: keep-alive
  5. Content-Length: 0
  6. Server: AliyunOSS
  7. x-oss-hash-crc64ecma: 14741617095266562575
  8. x-oss-next-append-position: 1717
  9. x-oss-request-id: 559CC9BDC755F95A64485981
本文导读目录
本文导读目录
以上内容是否对您有帮助?