You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: