Return a custom HTTP error from the datastore

[oliverpool]

How can I return a custom http error code from a custom datastore ?

For instance, if the file extension is not allowed, I would like to send back a http/403 with a reason file extension not allowed.
From the source, if my datastore returns an errors.New("403: File extension not allowed") it will be returned as a 500 error.

Could the unrouted_handler provide an error structure to customize the status code ?
Like return tusd.NewHttpError(403, "File extension not allowed") (if the error implements the HttpError interface, the status code is custom, otherwise it is set to 500).

The unrouted handler could also benefit from this (to remove the ErrStatusCodes map):

ErrUnsupportedVersion  = NewHttpError(http.StatusPreconditionFailed, "unsupported version")
ErrMaxSizeExceeded     = NewHttpError(http.StatusRequestEntityTooLarge, "maximum size exceeded")
...

[Acconut]

I do agree that this is a good idea. I will think a bit about how we can implement this is a proper way.

[oliverpool]

Maybe this could provide inspiration: https://elithrar.github.io/article/http-handler-error-handling-revisited/

[oliverpool]

One thought: in the documentation, it should be written that the datastores are supposed to work with any client; a custom http status must be appropriately!

• 1xx: Continuing process
• 2xx: Processed successfully
• 3xx: Redirection (no reason to be used, I think)
• 4xx: Client error (no need for the client to retry "as-is")
• 5xx: Server error (a later retry may succeed)

[oliverpool]

@Acconut : any update on this?

The final implementation of https://elithrar.github.io/article/http-handler-error-handling-revisited/ allows to be fully backward compatible! (thanks to the switch e := err.(type))

[Acconut]

I apologize for me belated response. Backwards-compatibility is not an issue I am concerned about but binding the data store implementations tightly to the HTTP protocol. Right now, the data stores have no knowledge that they are accessed using the HTTP protocol and keeping it like that has some advantages to separate the HTTP server accepting requests and the data store which takes care of handling the uploads. I haven't fully decided whether that's a big enough reason to prevent your feature request to be implemented or not but I will give it a try the next few days and then we will see.

[oliverpool]

I get your point about not only thinking about the http protocol.

Currently the specs only tells about http:

"The protocol provides a mechanism for resumable file uploads via HTTP/1.1 (RFC 7230) and HTTP/2 (RFC 7540)." https://tus.io/protocols/resumable-upload.html#abstract

And I think that if another protocol is supported at some point, it will also need a way to get some status about the transmission. Since the http status codes are well documented, they can be used as a basis to be translated to match the other protocol status codes.

Moreover I see no drawback into providing a custom error interface (StatusError{403, err} for instance) to categorize the errors:

• if you need the categorization at a later point in time, it's already available
• if you don't need it, you can still consider them as regular error

[Acconut]

I added a corresponding interface to address this issue. However, I am not entirely sure whether to keep the name, HTTPError. Will think about this a bit more :)