How to properly use Content-Type

[qsorix]

This is a continuation of a discussion from issue #14. I created a new issue because it's a completely different subject. But you should read the posts there too.

The topic here is: should the protocol specify Content-Type of valid requests, and if so, what for and what types to use?

[qsorix]

@evert wrote:

This is not unlike a REST-ish API supporting more than 1 format at any given endpoint. To do content-negotation for GET requests the Accept and Content-Type headers are used. Similarly, a server may support your protocol as well as this one http://sabre.io/dav/http-patch/ How can a server and/or client support both? (...)

Thanks, now I understand you. A server supporting both upload protocols is an interesting idea and I see how Content-Type can be used to achieve that.

I'm having a hard time coming up with a use case for this, especially today, when most servers support no resumable upload at all, but this doesn't mean it's invalid.

So now I'll just think out loud.

The way I see tus being used is via file-creation end point. In the response clients get a dedicated resource to represent the upload session, and this is tus and session specific. PATCH requests are sent there. To a tus specific location - I mean, to a location that is easy to make tus-specific.

The end point where File Creation requests are sent could support several protocols... but it also allows no content at all, so Content-Type is useless there, at least for tus, isn't it? Actually, Content-Type in File-Creation is used already, assuming we'll send metadata in the payload, as we currently plan to.

Hm. So to use Content-Type to differentiate between protocols an implementation would need to allow several protocols to be used while uploading a single file. This means a single client talking with a single server would want to change the protocol during the upload. Can you guys think of examples when this would be useful?

Hm. Maybe one file could actually be uploaded by several clients running different protocols?

If you think this is too complex, well, I don't have much to add then :)

I think this is too complex in the sense that it makes all implementations slightly harder, while providing no value in most (?) cases. But at the same time, I'm interested in exploring the possibilities. I wouldn't want to standardize things too soon, unless ignoring them prevents doing anything in the future. In other words, as soon as I understand this can be done later, I'll be convinced it should wait for someone with a real-life use case that we can study.

[Acconut]

In the response clients get a dedicated resource to represent the upload session, and this is tus and session specific. [...]
The end point where File Creation requests are sent could support several protocols

This seems to be a good plan. The upload URL should be tus specific. If you have multiple different upload protocols you could use different endpoints, e.g. /files/tus/cd61363a23cbbc0606ec6f2725b1224d.
The question is how file creation endpoint is able to know which protocol the client wants to use. In this case the TUS-Resumable header as discussed in #29 could help. By making it mandatory to be send in the request the server is capable to differentiate between the different protocols.

Hm. Maybe one file could actually be uploaded by several clients running different protocols?

In my opinion that's not something we need to discuss about now.

[kvz]

+1