Lack of Detail on Error Handling

[aubreyrees]

There seems to be lack of detail on how to handle errors in the Tus spec.

Specifically:

• It's not clear how the server should respond if the upload exceeds the server's maximum allowed size when the upload size is deferred or if the upload exceeds the size set by the Upload-Length header - should a 413 Request Entity Too Large response be sent as soon as the error is realised? If there is a mismatch between the uploads length and Upload-Length, should this be handled differently so the client can try and rectify the issue?
• There is limited information on how the server should handle errors in header values - for example, if Upload-Offset is negative. If the Upload-Defer-Length is not 1 the server should respond with 400 Bad Request, should the same be done for other headers? Does this extend to required but missing header fields, for example if Tus-Resumable is missing on requests not using the OPTION method?
• How should the server respond if the client uses a method that is supported by the server? This could be because it is not used at all (like GET) or because it is used by an unsupported extension (for example, without the Termination extension the DELETE method is unused).
• There is no mention of what the server should do in the event of a server error (say, IO error when writing an upload chunk to disk) - assuming a 5XX response, is there any exception of how clients should handle these?
• It's not made clear what header fields should be set on 4XX and 5XX responses. It seems Tus-Resumable should be included, but should any other header fields be set?

These questions came up while I was setting up a simple server to handle TUS requests without considering a particular client library. While a sane response can be guessed at there is no guarantee that a particular client will be in agreement with these guesses, or if there will be consensus amongst clients as to how to handle errors responses.

While these are relatively minor issues I believe it would help reduce friction between server and client implementations if these where addressed by the spec.

I suspect a lot of these cases are covered in tusd and for my implementation I will start reading through its code base, but it would still be best if the correct behaviour was canonicalised in the spec.

[aubreyrees]

I managed to miss #104 which seems to already cover a lot of these issues. I’ll raise and discuss any outstanding issues there. Closing this.