[eps]

What overhead is that exactly?

My point is that you appear to be pushing for adoption of an extension that handles one specific use case for PATCH, when a more general extension is trivially possible with little to no extra effort.

[kvz]

(I hope I understand your proposal correctly, I fear I might not, if so please clarify, but) more chunks come at the expense of more requests. After a connection drop each separate chunk needs to be renegotiated and transmitted. For some use cases that trade off is well worth it, like when latency is low, but tcp settings or QoS policies won’t let you saturate single connections, so tus does offer ‘sending multiple chunks by default and in parallel’, as an opt-in, via the Concat extension.

If your question is why not make Concat the default mode of operation, the additional roundtrips are the reason. For fragile connections these are often very costly, and we want tus to really shine in those situations, by default. If your users are all operating on big tubes, you’ll likely want to deploy Concat, but that’s not an assumption we want to make.