Failure Modes

[ronag]

• PATCH without content-length which writes more or less data than upload-offset + upload-length?
• Race when two clients send PATCH to same resource with matching upload-offset?
• Incompatible or missing rus-resumable header in request?
• Invalid content-type header in request?
• Invalid content-length header in request?
• Invalid defer-upload-length header in request?
• Invalid upload-length header in request?
• PATCH or POST does not have the correct content-type
• content-length doesn't actually match transferred length

Will add more to the list...

[Acconut]

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]

@Acconut: Added another one.

[Acconut]

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]

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]

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

[Acconut]

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]

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

[Acconut]

@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]

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]

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?