Q:

Amazon S3 Multipart Upload Async

I'm working with Amazon S3 multipart uploading and I read that you can upload parts of a file in parallel. However, looking through documentation I see that Amazon's response to an uploaded file part does not contain a part number. So my question is if I upload Part 1 of a file and Part 2 of a file asynchronously then I check for a response from Amazon how do I know if the response is referring to Part 1 or Part 2 of the file?
Here's an example request and response.
Request:
PUT /my-movie.m2ts?partNumber=1&uploadId=VCVsb2FkIElEIGZvciBlbZZpbmcncyBteS1tb3ZpZS5tMnRzIHVwbG9hZR HTTP/1.1
Host: example-bucket.s3.amazonaws.com
Date:  Mon, 1 Nov 2010 20:34:56 GMT
Content-Length: 10485760
Content-MD5: pUNXr/BjKK5G2UKvaRRrOA==
Authorization: AWS AKIAIOSFODNN7EXAMPLE:VGhpcyBtZXNzYWdlIHNpZ25lZGGieSRlbHZpbmc=

***part data omitted***

Response:
HTTP/1.1 200 OK
x-amz-id-2: Vvag1LuByRx9e6j5Onimru9pO4ZVKnJ2Qz7/C1NPcfTWAtRPfTaOFg==
x-amz-request-id: 656c76696e6727732072657175657374
Date:  Mon, 1 Nov 2010 20:34:56 GMT
ETag: "b54357faf0632cce46e942fa68356b38"
Content-Length: 0
Connection: keep-alive
Server: AmazonS3

A:

The Etag you get back in the response to each part is the md5sum of the part you just uploaded.
In the case of your example, unless I have made an error, your Content-MD5 decodes to a54357aff06328ae46d942af69146b38 ... so I would suggest that unless you have a problem with your MD5 calculation, the request and the response you've posted don't actually belong together.
The multipart uploader that I wrote is extremely pedantic because I use it to archive critical data (so pedantic, in fact, that it actually turns around and re-downloads the file after it thinks the multipart upload succeeded to be absolutely certain that the final product is perfect) ... but this utility submits the parts sequentially with a call that blocks and doesn't return until the response comes back... and one of its sanity tests is to compare the locally-calculated MD5 of the block with the Etag returned, and it's a fatal error if they don't match... so unless you have identical blocks, it would seem like you could correlate the parts that way.

additional:
I didn't use the missing body to calculate an md5 :) I took your header:
Content-MD5: pUNXr/BjKK5G2UKvaRRrOA==

Converted from base64 -> binary -> hex and got a54357aff06328ae46d942af69146b38.   
I do my verification downloads by stringing together 2 command line utilities, like this:
wget --server-response '$signed_url' -O - | md5sum

This downloads the file and pipes the bytes into md5sum for calculating the checksum, so I can download an infinitely-large file without using any disk space and very little memory.  The wget utility has built-in retrying capability and will try to continue from the byte position where it left off if something breaks the connection.  The outputs of this pipeline are the md5sum of the file (stdout) and the headers sent by the server and a progress meter (stderr).  My utility captures stdout and does the comparison, while letting stderr leak through to the console for observation.

