Describe limits for upload size about tus-resumable-upload-protocol HOT 5 CLOSED

Some HTTP frameworks I came across won't accept Content-Length values over a signed 32bit integer (2147483647 bytes, 2GB).

That seems client specific. But these clients could simply use 2GB as a chunk size instead of uploading the entire file during PUT requests?

On the other hand, the RFC mandates that the Content-Length header must be ignored if the transfer encoding is anything but identity (i.e. chunked transfer encoding):

The protocol currently says that Content-Length is required, so it seems that in accordance with RFC 2616, transfer codings can't be used with the protocol at this point. Do you think we should support them?

from tus-resumable-upload-protocol.

But these clients could simply use 2GB as a chunk size instead of uploading the entire file during PUT requests?

I believe so, yes.

Do you think we should support them?

Supporting non-identity encoding will add some complexity to the server side so I think you guys should stick to the simplest possible for now.

I honestly don't agree with that RFC line. I understand that chunked transfer encoding is great when you don't know the size beforehand but going as far as making a non-identity transfer-encoding and Content-Length header mutually exclusive is just silly (but I'm sure they must have had their reasons...).

For instance, on Droplr the server is currently violating that rule as I always need to know the size of the file before allowing the upload (user may have no more space, file may be too large for the free accounts, etc). It was either that or not supporting chunked transfer encoding at all. Since this is to become a more widely used standard you'll need a more elegant solution.

from tus-resumable-upload-protocol.

@brunodecarvalho ^--- proposed change for v0.2. What do you think?

from tus-resumable-upload-protocol.

Sounds good. Just a sanity check to see if I'm following along:

• Client reports its going to upload a 5GB file
• Client PUTs two chunks of 2GB-1 (here you should probably return 202 ACCEPTED, reserve 201 CREATED/200 OK for the final response)
• Client PUTs final 1GB chunk and gets OK from the server

So, assuming there were no Content-Length limits, it'd be nearly the same as trying to upload a 5GB file at once with failures occurring at the 2 and 4GB boundaries (which would lead to retries but in this case are answered with "ok, got this chunk, proceed")... Yeah, this looks great!

from tus-resumable-upload-protocol.

@brunodecarvalho yup - that's how it works!

from tus-resumable-upload-protocol.