search

tus / tus-resumable-upload-protocol

Open Protocol for Resumable File Uploads
https://tus.io
MIT License
1.48k stars 103 forks source link

Failure Modes #104

Open ronag opened 7 years ago

ronag commented 7 years ago

Will add more to the list...

Acconut commented 7 years ago

You are correct in that both of these cases are currently not covered in the specification.

Race when two clients send PATCH to same resource with matching upload-offset?

As a good starting point you should always avoid having two or more clients uploading to the same upload to avoid conflicts. If you are concerned that this may be an issue for you, the server should implement a locking mechanism to prevent further PATCH requests from modifying the resource. The tusd server has such a feature embedded.

ronag commented 7 years ago

@Acconut: Added another one.

Acconut commented 7 years ago

Incompatible or missing rus-resumable header in request?

Already defined:

If the the version specified by the Client is not supported by the Server, it MUST respond with the 412 Precondition Failed status and MUST include the Tus-Version header into the response. In addition, the Server MUST NOT process the request.

Invalid content-length header in request? Invalid defer-upload-length header in request? Invalid upload-length header in request?

There's a more general discussion in #79 which proposes stricter rules on how to react when invalid headers are presented. We probably should add a section about this.

Also, @ronag, please do not edit your original list but add a new comment. This will make it easier to follow.

ronag commented 7 years ago

Already defined:

The spec only defines If the the version specified by the Client is not supported by the Server. However, what if no version is specified, is that considered not supported?

ronag commented 7 years ago

What if PATCH or POST does not have the correct content-type?

Acconut commented 7 years ago

However, what if no version is specified, is that considered not supported?

Yes, I think it is safe to consider these cases to be equal.

ronag commented 7 years ago

@Acconut: For 1. Would it be appropriate to update the size to match the new one or should it be a 4xx error?

Acconut commented 7 years ago

@ronag For 1. Would it be appropriate to update the size to match the new one or should it be a 4xx error?

Once the upload length has been set, it must never be modified. If you want to append data, you can use the Concatenation extension. tusd handles this case differently. It will only accept as much data as fits into the upload and then ignore the rest. If the client tries to upload the rest afterwards, tusd will return an errors as it is not allowed to upload to an finished upload.

aubreyrees commented 4 years ago

How to handle an unused HTTP method doesn’t seem to covered by the spec - a 405 response seems sane.

Would there be value in distinguishing between methods unused in the spec and those not used because the prerequisite extension is not active? (Eg, DELETE is unused if the terminate extension is not enabled).

One use case for this could be when a extension is no longer used by a server as it would allow the client to differentiate between a client bug and a need to check the servers current extensions.

Acconut commented 4 years ago

How to handle an unused HTTP method doesn’t seem to covered by the spec - a 405 response seems sane.

Yes, a 405 response would be the correct response here. However, I don't think we need to add this to the tus specification as this is already covered in the HTTP specification (as far as I know). Since tus builds upon HTTP, the HTTP spec applies for tus server and clients as well. What do you think?