The tus.io/demo does not meet the protocol specification

Hi,

I started to experience a bit with the TUS protocol.
Instead of using my own server, I’m using the tus demo server (https://tusd.tusdemo.net/files/).
I found two issues with it so far.

  1. The “Content-Length” field must be included in any PATCH request. Otherwise, the server
    returns “Error: system lib” without accepting the payload.
    This restriction was removed from the protocol on PR 137 (https://github.com/tus/tus-resumable-upload-protocol/pull/137), more than two years ago.

  2. For some reason, the server does not reply to HEAD requests.

Both issues are in the Core Protocol and quoting from the protocol itself: “All Clients and Servers MUST implement the core protocol”.

So, if my observation is correct, the demo server is not compliant with the protocol and it is a pity.

In my opinion, the demo server should support the specification exactly as described so developers can play with it to have a better understanding of the protocol.

Best,
Gil

Hi Gil,

thanks for your report but I am not able to reproduce your issues. In my tests, the tus demo server responded fine to HEAD requests and PATCH requests without Content-Length. There are no known inconsistencies between the demo server and the protocol specification.

Could it be that there is some issue on your end with the requests? Can you provide us with a way to reproduce these requests?

Hi Marius,

Thanks for the reply.

I created a simple C++ app which demonstrate the two issues.
The C++ app depends on the (Boost)[https://www.boost.org/] library and is based on their (example)[libs/beast/example/http/client/sync-ssl/http_client_sync_ssl.cpp - 1.75.0].

If you’re having trouble building it or for any other reason, prefer to have a pre-build Windows/Linux app, please ask, and I’ll build it for you.

Like I mentioned.
Calling PATCH without “Content-Length” won’t upload the file.
Calling HEAD won’t return any response from the server.

Thanks,
Gil

Hi Gil,

I do not have the knowledge to create a C++ application on my own to reproduce your issues. However, since the tusd server is working correctly with all other clients (JavaScript, Java, Python, cURL, Go, etc), I highly suspect that there is an error in your application. Out of my head, there are two possible pitfalls:

If you do not set Content-Length, you must use the Transfer-Encoding: chunked header and properly encode the request body for chunked transfer. This is not specific for tus, but defined by the HTTP standard AFAIK. Maybe the boost HTTP library does not do this by default.

The response to HEAD requests does not include any body, according to the HTTP specification. Maybe your application is waiting for our server to respond with a body, which is not going to be sent for HEAD response?

If you want to share your source code, maybe we can help more.