How is an HTTP multipart "Content-length" header value calculated? -

i've read conflicting , ambiguous replies question "how multipart http request content length calculated?". wonder:

• what precise content range "content-length" header calculated?
• are crlf ("\r\n") octet sequences counted 1 or 2 octets?

can provide clear example answer these questions?

the following live example should answer questions.

perform multipart request google's oauth 2.0 playground

google's oauth 2.0 playground web page excellent way perform multipart http request against google drive cloud. don't have understand google drive -- i'll work you. we're interested in http request , response. using playground, however, allow experiment multipart , answer other questions, should need arise.

create test file uploading

i created local text file called "test-multipart.txt", saved somewhere on file system. file 34 bytes large , looks this:

we're testing multipart uploading! 

open google's oauth 2.0 playground

we first open google's oauth 2.0 playground in browser, using url https://developers.google.com/oauthplayground/:

fill in step 1

select drive api v2 , "https://www.googleapis.com/auth/drive", , press "authorize apis":

fill in step 2

click "exchange authorization code tokens":

fill in step 3

here give relevant multipart request information:

• set http method "post"
• there's no need add headers, google's playground add needed (e.g., headers, boundary sequence, content length)
• request uri: "https://www.googleapis.com/upload/drive/v2/files?uploadtype=multipart"
• enter request body: meta-data json required google drive perform multipart upload. used following:

 {"title": "test-multipart.txt", "parents": [{"id":"0b09i2zh5ssthtjntss9qyuzqdta"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]} 

• at bottom of "request body" screen, choose test-multipart.txt file uploading.
• press "send request" button

the request , response

google's oauth 2.0 playground miraculously inserts required headers, computes content length, generates boundary sequence, inserts boundary string wherever required, , shows server's response:

analysis

the multipart http request succeeded 200 status code, request , response ones can depend upon. google's playground inserted needed perform multipart http upload. can see "content-length" set 352. let's @ each line after blank line following headers:

 --===============0688100289==\r\n content-type: application/json\r\n \r\n {"title": "test-multipart.txt", "parents": [{"id":"0b09i2zh5ssthtjntss9qyuzqdta"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]}\r\n --===============0688100289==\r\n content-type: text/plain\r\n \r\n we're testing multipart uploading!\r\n --===============0688100289==-- 

there 9 (9) lines, , have manually added "\r\n" @ end of each of first 8 (8) lines (for readability reasons). here number of octets (characters) in each line:

1. 29 + '\r\n'
2. 30 + '\r\n'
3. '\r\n'
4. 167 + '\r\n'
5. 29 + '\r\n'
6. 24 + '\r\n'
7. '\r\n'
8. 34 + '\r\n' (although '\r\n' not part of text file, google inserts it)
9. 31

the sum of octets 344, , considering each '\r\n' single one-octet sequence gives coveted content length of 344 + 8 = 352.

summary

to summarize findings:

1. the multipart request's "content-length" computed first byte of boundary sequence following header section's blank line, , continues until, , includes, last hyphen of final boundary sequence.
2. the '\r\n' sequences should counted 1 (1) octet, not two, regardless of operating system you're running on.