Closed csarven closed 4 weeks ago
PS: the HTTP Police aka HTTPWG has ruled that it is not header but field or header field. I guess we'll need a separate PR for that!
Thanks for the heads up. The specification already uses "header field" (as well as "field value") in some parts so I guess some instances were missed. I went ahead and made that change to clarify in https://github.com/solid/specification/commit/93901540e7efd22ce48692deb4298df30ea4c2a7 and it is integrated in this PR.
Preview | Diff
Summary:
Content-Type
header, particularly when the request message includes content, can potentially confuse servers and cause issues with existing or future implementations.PUT
andPATCH
requests can be used to create a container if the target URI ends with a slash (/
) and the message content is empty, even without theContent-Type
orLink
headers indicating an LDP container.POST
requests to create a container essentially depends on theLink
header indicating an LDP container (or possible alternative considerations that were contemplated in the past).This PR makes a correction class 3 change:
Slug
header is not widely implemented and should not be used to match existing resources ( https://github.com/solid/specification/pull/621 ).A more high level explanation of the changes:
Servers conforming to the Solid Protocol can create a container using
PUT
andPATCH
requests without theContent-Type
header, provided that the message content is empty. Similarly, LDP server conformance generally requires the use of aContent-Type
header when there is message content, and the behaviour without aContent-Type
header is unspecified.Where a server accepts a
POST
request with aLink
header indicating the LDP container type but without aContent-Type
header, the server could potentially conform to the Solid Protocol (given changes to the specification) but no conformance to LDP is unspecified.The use case for servers assigning a URI for containers (e.g.,
/{uuid}/
) withPOST
requests is generally uncommon.To avoid potential conflicting requirements across specifications, it would be preferable not to specify that
POST
requests can create containers, regardless of theContent-Type
header being omitted when message content is empty. LDP servers are not required to create containers that way either. This can make sure that Solid servers remain compatible with LDP servers without necessarily restricting container creation.Background drawing from HTTP specs, LDP, and Solid Protocol specs:
In https://www.rfc-editor.org/rfc/rfc9110#section-9.3.3-1 :
Server's expectation is that
Content-Type
is included in the request (irrespective to resource semantics).In https://www.rfc-editor.org/rfc/rfc9110#section-8.3-5 :
At the moment, the Solid Protocol tries to be strict on this point https://solidproject.org/ED/protocol#server-content-type-missing by requiring
Content-Type
, and generally on the basis of discouraging heuristics to figuring out representation's type ( https://www.rfc-editor.org/rfc/rfc9110#section-8.3-6 ). LDP is however more relaxed on this (see below)While LDP does not generally describe or prohibit an interaction model to create a container ( https://www.w3.org/TR/ldp/#ldpc-post-createrdf ) with
POST
withoutContent-Type
:it does explain the process to create LDP-RSs where it also includes the
Content-Type
header, emphasis on "creation of LDP-RS", which includes all LDP container types ( https://www.w3.org/TR/ldp/#ldpc-isldpr ):https://www.w3.org/TR/ldp/#ldpc-post-turtle :
https://www.w3.org/TR/ldp/#ldpc-post-jsonld :
Essentially LDP does not specify conformance for
POST
requests withoutContent-Type
and without message content. No interoperability between servers and clients specified. It doesn't even specify forPUT
.LDP also notes the possibility that servers might infer the content type (when the
Content-Type
header is missing) by sniffing ( https://www.w3.org/TR/ldp/#ldp-http-content-sniffing ), which is also summarised in https://github.com/solid/specification/issues/70#issuecomment-536684883 :While content type sniffing is discouraged in Solid Protocol ( https://github.com/solid/specification/issues/70#issuecomment-547924171 ) the context of the discussion and the requirements that lead to it in the Solid Protocol was for requests including a message. It is important to maintain that case. However, when the request does not include content, and the request semantics does not require the
Content-Type
header, then it is possible to have a valid request without theContent-Type
header.Solid Protocol defines a container as a hierarchical collection of resources ( https://solidproject.org/ED/protocol#container-resource ) - not limited to LDP:
but the described normative behaviours correspond to LDP Basic Container ( https://solidproject.org/ED/protocol#server-basic-container ):
With resource type heuristics ( https://solidproject.org/ED/protocol#resource-type-heuristics ) in Solid Protocol, it is possible to create a container without a
Content-Type
header if the request's target URI ends with a slash (/
):https://solidproject.org/ED/protocol#uri-slashes-hierarchical-identifier :
The ways in which PUT, PATCH, and POST can be used to create containers and URI assignment are based on determining the request semantics from HTTP request method ( https://www.rfc-editor.org/rfc/rfc9110#section-9 ). Summarised in:
https://solidproject.org/uri-allocation-put-patch :
https://solidproject.org/uri-allocation-put-patch :
https://solidproject.org/ED/protocol#server-post-target-not-found
Essentially only
PUT
andPATCH
can be used to create a container in such requests.Additional background on determining resource type was outlined here https://github.com/solid/specification/pull/160#issuecomment-635932724 , based on use cases borrowed from LDP where 1) the requirements building on from HTTP (as opposed to LDP), and 2) aiming to not conflict with LDP and be compatible as needed.
As it currently stands in the Solid Protocol, the only interoperable way for Solid Protocol to create a container with
POST
is by:where it only meets the functional requirement:
The
Slug
header is not required in Solid Protocol or LDP, and it is deemed to be unreliable or problematic ( https://github.com/solid/specification/pull/621 ).