TON api multi-chunk upload errors HTTP/400

[pykler]

Range=bytes 70368744177664-70368752566271/4350085740

Your first PUT request should have the range 0-XXX/YYYY

where XXXX is the chunksize-1 and YYYY is the full size of the doc as you sent in the X-TON-Content-Length in the first call.

Your numbers are way off.

Also you do not need the X-TON calls for the PUT requests, just for the first POST.

[liviutudor]

@pykler Ok, so there seems to be an overflow that sneaked in the code somehow which does indeed mess up the number and we’ll be looking into that.

Your reply makes an interesting point thought about the initial PUT: the very first PUT that follows the initial POST must have the range 0-XXXX/YYY or can it be any other range?

The reason why I am asking is because after the initial POST, we are piping all the PUT requests through a thread pool and as such have no control over the schedulling – which means the first PUT could end up being for a chunk in the file which is not the first one. (And lookin at the logs here, while the numbers are indeed off, this is definitely the case where the initial chunks uploaded are from somewhere in the middle of the file – so the range doesn’t start with 0.)
Do we have to ensure the initial PUT has the range 0-XXX?

Secondly, do these chunks have to be uploaded in order?

For instance, imagine this scenario (I’m using small numbers here just to exemplify, I am aware of the size requirements etc): file a.txt gets split in 4 chunks :

1. 0-9
2. 10-19
3. 20-29
4. 30-39

Let’s say that the initial chunk upload is for chunk 1 (0-9) then the other 3 uploads go through a thread pool so they end up being uploaded in this order:

1. chunk 4 (30-39)
2. chunk 2 (10-19)
3. chunk 3 (20-29)

Will this fail when uploading to TON or will it work? Does the chunk upload have to follow the order 1,2,3,4?

Thanks,

[pykler]

I have not tested but I would think they have to be sequential and in order. Try confirming that the sequential upload works first then parallelize the solution (that would be my approach).

[liviutudor]

OK I will give that a go, however, if the sequential order is required this is a huge issue for the TON API because it means uploading large files cannot be optimized in any way and becomes a bottleneck.

[liviutudor]

@pykler just validated going through the code that the overflow issue was just a reporting (logging) issue, the chunks were actually send the correct size but I think the problem was the order of the chunks which I am trying to confirm.

[liviutudor]

@pykler and are you also saying that for the PUT requests (after the initial POST) none of the X-TON… headers are required? Does it cause issues if they are present?

[liviutudor]

OK so having done all of that and ensure the first PUT is the range 0…XXX I am still getting HTTP/400 – here are some details:

{X-TON-Expires=Sat, 13 Jun 2015 13:50:39 UTC, Content-Range=bytes 0-4194303/5948800, X-TON-Content-Type=text/comma-separated-values, Content-Type=text/comma-separated-values}

This is part of a test trying to upload a 5Mb file into chunks of 4Mb. The content sent is is the size advertised in the headers. The initial POST was successful and this is the very first PUT yet it’s failing.

Ideas?

[brandonmblack]

@liviutudor are you still doing the uploads in parallel or did you switch it to perform the upload sequentially?

[liviutudor]

@brandonmblack They are going sequentially for this test.

[liviutudor]

would a 400 occur if the upload takes longer than 30 seconds?

[pykler]

@liviutudor If your file is less than 8MB you cannot send it with resumable. It can only be sent as a single chunk. This is undocumented but I have tested it and mentioned it in the previous thread.

If your file is greater than 8MB you can chunk it. The POST request has some headers that tell you the min and max chunk size.

[pykler]

The initial POST though was never successful for me, if the content-length is too small (less than 8MB).

[pykler]

X-TON-Expires

Can you not use the X-TON parameters in your PUT request. I haven’t tested with those, but the PUT does not need any X-TON params.

[liviutudor]

I’m actually using a chunk size of 8Mb since this seems to be the “preferred” size for Twitter. It is within the boundaries of min/max chunks size coming back from TON from what I can see. However I am seeing intermitently HTTP/308 (which seems to indicate success) but most time it’s a 400

[liviutudor]

Good point ok I’ll remove those and give it another try.

[liviutudor]

P.S. I swear the docco used to show the TON headers in PUT before.

[pykler]

Once you get a 400 usually the rest are all 400 to follow. Essentially though a 400 means nothing was accepted, so if you fix that request perhaps you should get the 308 and proceed.

[liviutudor]

OK so removing the headers and sending chunks sequentially now works for uploading files to TON. However, a 4 Gb file now takes ~25 min

I am getting 400 errors from the TA API when applying the change (see below) so I’m wondering if the file was not assembled back together properly – is that possible? How can I check?

This is the message I’m getting when passing the TON file to the TA

[makeAudienceChange] Got response from Twitter for audience change:HttpResponseProxy{HTTP/1.1 400 Bad Request [content-disposition: attachment; filename=json.json, content-type: application/json;charset=utf-8, date: Tue, 09 Jun 2015 19:18:23 GMT, server: tsa_b, strict-transport-security: max-age=631138519, x-access-level: read-write, x-connection-hash: eaf79ab917d8066d6450f648cb5a2296, x-content-type-options: nosniff, x-frame-options: SAMEORIGIN, x-rate-limit-limit: 300, x-rate-limit-remaining: 300, x-rate-limit-reset: 1433877563, x-response-time: 27, x-runtime: 0.018034, x-transaction: 1558ec954bc257a7, x-xss-protection: 1; mode=block] org.apache.http.client.entity.DecompressingEntity@7d7987ef}

P.S. Happy to move this to a separate thread if this is definitely no longer related to TON (i.e. if once the last chunk is uploaded and I get a 201 it’s for certain the file has been assembled back together properly).

[liviutudor]

I am now convinced it is the multi-chunk upload in TON causing this, because if I run exactly the same audience change code but with a small file upload (which does not require chunks upload) , when I apply the audience change it works fine.

So how does the TON multi-chunk upload affect TA changes? Or why am I getting HTTP/400 in case of a multi-chunk upload and 200 for small file?

[liviutudor]

OK so I think the issue is to do with the paths returned from single upload versus multiple chunk rather than the pasting the chunks together.
I seem to pass the “resumeable” URL rather than the last received in the last chunk which I believe was causing the issue.
Fixing that seems to make my tests pass again and the audience changes are applied now.