Processing HTTP messages

[csarven]

Background: The Solid protocol requires servers to reject PUT, POST, PATCH requests without the Content-Type header ( #server-content-type ). The rationale was to avoid unclarity / variability in servers when Content-Type is not present and the cost of servers and clients to deal with the consequences. This is "strict" from the point of the protocol, and improves the simplicity and security of the system.

The Solid Protocol (as per https://solidproject.org/TR/2021/protocol-20211217 and https://solidproject.org/ED/protocol as of this writing) does not require receivers to process the HTTP message body, unless otherwise specified, e.g., #n3-patch for Content-Type: text/n3.

Should the Solid Protocol require how receivers process HTTP messages (in the context of the Content-Type provided)? Consider cases where the payload is invalid once parsed, as per, e.g., a concrete RDF syntax.

There is a whole paragraph on numerous considerations in https://solidproject.org/TR/protocol#consider-request-validation that touches the concern here. The question is whether there should be a particular requirement or additional advisory.

[csarven]

One example:

The cost for clients to process invalid IRIs in RDF messages and the consequences could be much higher than the cost for servers that do want to process and reject the request [citation needed].

There is also a security concern if (authorization) servers apply vendor-specific algorithms that apply transformations upon receiving the request or when resource representations are applied elsewhere in the system.