Object Storage Service：AppendObject

通過Append Object操作建立的Object類型為Appendable Object，而通過Put Object上傳的Object是Normal Object。

請求文法

POST /ObjectName?append&position=Position HTTP/1.1
Content-Length：ContentLength
Content-Type: ContentType
Host: BucketName.oss.aliyuncs.com
Date: GMT Date
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 或 KMS 说明 您需要購買KMS套件，才可以使用KMS密碼編譯演算法，否則會報KmsServiceNotEnabled錯誤碼。
x-oss-object-acl	字元串	指定oss建立object時的存取權限。 合法值：public-read，private，public-read-write

響應Header

和其他動作的關係

• 不能對一個非Appendable Object進行Append Object操作。例如，已經存在一個同名Normal Object時，Append Object調用返回409，錯誤碼ObjectNotAppendable。
• 對一個已經存在的Appendable Object進行Put Object操作，那麼該Appendable Object會被新的Object覆蓋，類型變為Normal Object。
• Head Object操作會返回x-oss-object-type，用於表明Object的類型。對於Appendable Object來說，該值為Appendable。對Appendable Object，Head Object也會返回上述的x-oss-next-append-position和x-oss-hash-crc64ecma。
• Get Bucket（List Objects）請求的響應XML中，會把Appendable Object的Type設為Appendable
• 不能使用Copy Object來拷貝一個Appendable Object，也不能改變它的伺服器端加密的屬性。可以使用Copy Object來改變用戶自訂元資訊。

細節分析

• URL參數append和position均為CanonicalizedResource，需要包含在簽名中。
• URL的參數必須包含append，用來指定這是一個Append Object操作。
• URL查詢參數還必須包含position，其值指定從何處進行追加。首次追加操作的position必須為0，後續追加操作的position是Object的當前長度。例如，第一次Append Object請求指定position值為0，content-length是65536；那麼，第二次Append Object需要指定position為65536。每次操作成功後，回應標頭部x-oss-next-append-position也會標明下一次追加的position。
• 如果position的值和當前Object的長度不一致，OSS會返回409錯誤，錯誤碼為PositionNotEqualToLength。發生上述錯誤時，用戶可以通過回應標頭部x-oss-next-append-position來得到下一次position，並再次進行請求。
• 當Position值為0時，如果沒有同名Appendable Object，或者同名Appendable Object長度為0，該請求成功；其他情況均視為Position和Object長度不匹配的情形。
• 當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請求。
• 由於並發的關係，即使用戶把position的值設為了x-oss-next-append-position，該請求依然可能因為PositionNotEqualToLength而失敗。
• Append Object產生的Object長度限制和Put Object一樣。
• 每次Append Object都會更新該Object的最後修改時間。
• 在position值正確的情況下，對已存在的Appendable Object追加一個長度為0的內容，該操作不會改變Object的狀態。

CRC64的計算方式

Appendable Object的CRC採用ECMA-182標準，和XZ的計算方式一樣。用Boost CRC模組的方式來定義則有：

typedef boost::crc_optimal<64, 0x42F0E1EBA9EA3693ULL, 0xffffffffffffffffULL, 0xffffffffffffffffULL, true, true> boost_ecma;

uint64_t do_boost_crc(const char* buffer, int length)
{
    boost_ecma crc;
    crc.process_bytes(buffer, length);
    return crc.checksum();
}

或是用Python crcmod的方式為：

do_crc64 = crcmod.mkCrcFun(0x142F0E1EBA9EA3693L, initCrc=0L, xorOut=0xffffffffffffffffL, rev=True)

print do_crc64(“123456789”)

樣本

請求樣本：

POST /oss.jpg?append&position=0 HTTP/1.1
Host: oss-example.oss.aliyuncs.com
Cache-control: no-cache
Expires: Wed, 08 Jul 2015 16:57:01 GMT
Content-Encoding: utf-8
Content-Disposition: attachment;filename=oss_download.jpg
Date: Wed, 08 Jul 2015 06:57:01 GMT
Content-Type: image/jpg
Content-Length: 1717
Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:kZoYNv66bsmc10+dcGKw5x2PRrk=

[1717 bytes of object data]

返回樣本：

HTTP/1.1 200 OK
Date: Wed, 08 Jul 2015 06:57:01 GMT
ETag: "0F7230CAA4BE94CCBDC99C5500000000"
Connection: keep-alive
Content-Length: 0  
Server: AliyunOSS
x-oss-hash-crc64ecma: 14741617095266562575
x-oss-next-append-position: 1717
x-oss-request-id: 559CC9BDC755F95A64485981