Clarification needed re: Chunked Transfer Encoding

Asked by Bob

Hi,

Re: 3.3.2.1. Chunked Transfer Encoding

The docs say :
Users can upload data without needing to know in advance the amount of data to be uploaded. Users can do this by specifying an HTTP header of Transfer-Encoding: chunked and not using a Content-Length header

Could someone please clarify the wording :

(1) Does this mean it is illegal syntax to supply a "Content-Length" header when using chunked encoding ? Or does it only mean that the "Content-Length" header is optional when using chunked encoding, and hence if I *DO* know the content-length, I can provide it, and the API will use it ?

(2) Similar question in relation to provision of Etag MD5 hash.

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Object Storage (swift) Edit question
Assignee:
No assignee Edit question
Solved by:
Bob
Solved:
Last query:
Last reply:
Revision history for this message
gholt (gholt) said :
#1

If you know the content length, you don't need to use chunked transfer encoding because, you know the content length. :) According to the HTTP spec http://www.ietf.org/rfc/rfc2616.txt "If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored." I'm uncertain whether that specific case is accounted for in Swift.

The etag is optional but will be computed and stored for you if you don't provide it. Providing an etag is just extra assurance the transfer was not corrupted somehow.

Revision history for this message
Bob (rclocal) said :
#2

Hi,

Thanks for this.

Discoverd the RFC in the interim period, so it was more the etag I wanted to verify.