Wow this is pretty interesting… Here are the details on how they are doing this…
They only offer a cancel on the upload but the do provide a % indicator while the upload is happening..
I can verify that once you add the file it appears that they store that item into the Local Gears Database because when you come back to the page it is still there.
I have attached some of the headers and footers in this email (please don’t hack my account with the cookies :)
/login call on upload.youtube.com is of interest as they carry a cookie along for the ride that appears to be the YouTube "user identifier" but on the body of the request it contains the following
plus the Login Request header used a Content-Type: application/octet-stream which is very interesting. There is also a couple of "Miscellaneous" headers but one of them interests me and is X-GUploader-Client-Version: 2.0.0 (make a mental note of that for future reference.) Note that in the Respone the send back a Cookie (Set-Cookie: SID=ukWauHLkGDpxrm-s)
The /stat call sent a 404 but that really means nothing. They probably recorded some info but what I do see of interest is the following
They do send an Entity Request Header of Content-Disposition: attachment; filename="ukWauHLkGDpxrm-s" which came from the /login call which appears to prep the upload.youtube.com system for the beginning of the upload.
The "first", "second" and "last" upload requests are of interest and all carry the SID Cookie above to let the system know which file is being uploaded. They all also carry
X-GUploader-Metadata: filename="ShanghaiIntelView.MOV"; title="ThisIsATestDelete"; token="6829462C852ABA9D:53C662DC848F75CD"
This token appears first in the upload page HTML
http://www.youtube.com/my_videos_multiupload in a code call to SetMetaData(f, 's', '6829462C852ABA9D:53C662DC848F75CD'); in the page.. I made a couple of page requests to this file and note that it changes the value every time (each re-request.)
"first" one contains (of interest) the HTTP FORM FIELD DATA but none of the actual file being uploaded
Content-Range: bytes 0-2115/8607324
Content-Disposition: form-data; name="vidcap_upload_key"
Content-Disposition: form-data; name="field_myvideo_categories"
etc… and at the end this...
Content-Disposition: form-data; name="Filedata"; filename="ShanghaiIntelView.MOV"
Content-Range: bytes 2116-1050691/8607324 Which looks like a split of the first part of the MOV file into sections with the first section being a partial (less the initial part of the POST data)
etc.. with each next part a split of the file
till the "last" part which is the final part of the file..
They do have a cancel button which causes the process to abort but no information is sent back to the server that the upload was stopped..