Relax mandatory content-type header field requirement for PUT, POST with no content body.

[CxRes]

It is the case that PUT and POST requests might be made without a content body, such as in the case of creating containers. In such cases, mandating a content-type header field seems an absurd requirement, for there is no content (This does not preclude the opportunity for a client to specify a media-type, if it so wishes).

From RFC9110 Section 8.3:

A sender that generates a message containing content SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender.

There is no requirement as far as RFC9110 is concerned that a content-type be provided in the absence of a body.

Further, the LDP spec in 5.2.3.4 and 5.2.3.12 only demands of clients, when they provide bodies in POST requests, must be of suitable content-types (turtle and json-ld resp.) which is specified in the content-type header. That the LDP spec goes out of its way to specify this implies, there is no requirement outside these cases in which a POST request needs to specify any content-type, beyond the obvious requirements of RFC9110 (then RFC7321) above.

[CxRes]

Now @csarven and I have an ongoing discussion (starting). He principally makes two arguments against my contention (which I shall try to reproduce to the best of my ability, and he can of course correct):

1. "How could the media type be supposedly be unknown by the sender if it is literally aware of LDP-BC? There is no significant / strong reason as to why a client or server wouldn't know what they are sending." and further suggests that he is unaware of any library that uses a LDP interaction model that "is somehow capable or willing to use the Link relation with LDP-BC but somehow doesn't include Content-Type: text/turtle".

2. Further to the statement I cite from the RFC9110, he cites:

   "If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type."

   He contends that a server might interpret a message without content-type (even without content) as to be represented as application/octet-stream, which is incorrect or guess it to be LDP-RS, which (MIME sniffing) is discouraged. Hence, a content-type must be provided at all times

I refute those arguments based on the points in the first comment and that the two RFC9110 statements in the two comments must be read together (and the second one continues from the first)!

[csarven]

#660 is a proposal to relax / clarify that Content-Type is needed when the request message has content.

That aside, POST to create a container all things considered is not a good idea as I see it, regardless of trying to navigate through with or without Content-Type (with or without message content). It requires dependency on using LDP container type in the request Link relation that the Solid Protocol can do without. PUT and PATCH are possible and reliable as it stands. I suggest using them instead.