[kvz]

Hi, one of the authors here. It would, but traffic shaping is not part of the protocol itself and by default tus will saturate available connections.

That said we're writing down some recommendations in a separate 'developer guide' document that offers best practices for implementing and deploying tus, traffic shaping could be part of it. Feel free to weigh in here https://github.com/tus/tus-resumable-upload-protocol/pull/68

[amelius]

I think traffic shaping is very desirable when using a websocket for a separate command-channel. The last thing you want is an upload blocking all communications over that command-channel.

Furthermore, browsers can open only a maximum number of connections at the same time (I believe the maximum on some browsers is even just 2). What if the application already uses one connection for a websocket? Will there be only 1 connection left for the upload? And what if the browser needs to download other resources in the background, such as images, fonts, etc.?

Just some concerns, good luck with the project :)

[kvz]

Some valid concerns indeed! You may run dedicated uploading infra which allows more connections (different subdomain/IPs), but it's something we want to be explicit about in our developer guidelines, I'll also see if we can make traffic shaping part of the js browser implementation, as this seems to need it most - thanks!