LDP does not specify URI patterns for resources when using the POST method, e.g., POST http://example.org/foo/ may result in creating a resource with URI http://example.org/foo/bar, http://example.org/baz/qux/quxx, http://example.org/{uuid} or something else. In Solid Protocol, the URI of a new resource resulting from, e.g., POST http://example.org/foo/, is in context of the request URI, and therefore http://example.org/foo/bar will be created, and it is not possible to construct the new URI besides under the direct hierarchy of http://example.org/foo/.
Solid Protocol's server behaviour in that regard is compatible with LDP even if only ldp:Container is advertised in the HTTP Link header of the request URI, i.e., http://example.org/foo/ as the effective request URI of POST. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around POST to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from POST requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.
Solid Protocol's server behaviour in that regard is compatible with LDP even if only ldp:Container is advertised in the HTTP Link header of the request URI, i.e., http://example.org/foo/ as the target URI of POST. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around POST to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from POST requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.
Solid Protocol clients may not fully interoperate with LDP servers, e.g., it is possible for an LDP server implementation to assign URIs to new resources that are not compatible with Solid Protocol. An LDP server needs to also conform to Solid Protocol server requirements in order to participate in the Solid ecosystem.
@@ -666,30 +666,26 @@Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].
+Servers MUST conform to HTTP Semantics [RFC9110]. Servers SHOULD conform to HTTP Caching [RFC9111]. Servers MUST conform to HTTP/1.1 [RFC9112]. Servers SHOULD conform to HTTP/2 [RFC9113].
Servers SHOULD use TLS connections through the https URI scheme in order to secure the communication with clients. When both http and https URI schemes are supported, the server MUST redirect all http URIs to their https counterparts using a response with a 301 status code and a Location header.
Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].
+When a client does not provide valid credentials when requesting a resource that requires it (see WebID), servers MUST send a response with a 401 status code (unless 404 is preferred for security reasons).
Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. When a client does not provide valid credentials when requesting a resource that requires it (see WebID), servers MUST send a response with a 401 status code (unless 404 is preferred for security reasons).
Server MUST generate a Content-Type header field in a message that contains content.
Server MUST generate a Content-Type header field in a message that contains a payload body.
Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]
Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]
Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].
- -Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].
+Clients MUST conform to HTTP Semantics [RFC9110]. Clients MAY conform to HTTP Caching [RFC9111]. Clients MUST conform to HTTP/1.1 [RFC9112]. Clients MAY conform to HTTP/2 [RFC9113].
-Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.
When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.
Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]. [Source]
Clients MUST use the Content-Type HTTP header in PUT, POST, and PATCH requests [RFC9110]. [Source]
When creating new resources, servers can determine an effective request URI’s type by examining the URI path ending (URI Slash Semantics).
+When creating new resources, servers can determine a target URI’s type by examining the URI path ending (URI Slash Semantics).
-When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.
When a successful PUT or PATCH request creates a resource, the server MUST use the target URI to assign the URI to that resource.
When a successful POST request creates a resource, the server MUST assign a URI to that resource. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].
Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options. [Source]
Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC9110] for clients to read resources or to determine communication options. [Source]
Servers MUST indicate the HTTP methods supported by the target resource by generating an Allow header field in successful responses.
Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [Source] [Source]
Servers MUST support the HTTP PUT, POST and PATCH methods [RFC9110]. [Source] [Source]
Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests. [Source]
Servers MUST support the HTTP DELETE method [RFC7231]. [Source] [Source]
Servers MUST support the HTTP DELETE method [RFC9110]. [Source] [Source]
When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231]. [Source]
When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC9110]. [Source]
When a contained resource is deleted, the server MUST also remove the corresponding containment triple. [Source]
@@ -1047,7 +1043,7 @@This section is non-normative.
-The server might perform additional actions, as described in the normative references like [RFC7231]. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.
+The server might perform additional actions, as described in the normative references like [RFC9110]. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.
Subsequent GET requests to the deleted resource usually result in a 404 or 410 status code, although HTTP allows others. [Source] [Source]
A server MUST implement the CORS protocol [FETCH] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the server, and the Solid app can read any response and response headers received from the server. If the server wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as 401, 403, or 404 [RFC7231].
A server MUST implement the CORS protocol [FETCH] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the server, and the Solid app can read any response and response headers received from the server. If the server wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as 401, 403, or 404 [RFC9110].
Concretely, whenever a server receives an HTTP request containing a valid Origin header [RFC6454], the server MUST respond with the appropriate Access-Control-* headers as specified in the CORS protocol [FETCH]. In particular, the server MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value. The server MUST make all used response headers readable for the Solid app through Access-Control-Expose-Headers (with the possible exception of the Access-Control-* headers themselves). A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.
Concretely, whenever a server receives an HTTP request containing a valid Origin header [RFC6454], the server MUST respond with the appropriate Access-Control-* headers as specified in the CORS protocol [FETCH]. In particular, the server MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value. The server MUST make all used response headers readable for the Solid app through Access-Control-Expose-Headers (with the possible exception of the Access-Control-* headers themselves). A server MUST also support the HTTP OPTIONS method [RFC9110] such that it can respond appropriately to CORS preflight requests.
Careful attention is warranted, especially because of the many edge cases. For instance, servers SHOULD explicitly enumerate all used response headers under Access-Control-Expose-Headers rather than resorting to *, which does not cover all cases (such as credentials mode set to include). Servers SHOULD also explicitly list Accept under Access-Control-Allow-Headers, because values longer than 128 characters (not uncommon for RDF-based Solid apps) would otherwise be blocked, despite shorter Accept headers being allowed without explicit mention.
This specification introduces a new HTTP response header Accept-Put used to specify the document formats accepted by the server on HTTP PUT requests. It is modelled after the Accept-Patch header defined in [RFC5789] and the Accept-Post header defined in [LDP].
The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:
The syntax for Accept-Put, using the ABNF syntax defined in Section 2.1 of [RFC9110], is:
Accept-Put = "Accept-Put" ":" # media-range+
Accept-Put = "Accept-Put" ":" #media-range-
The Accept-Put header specifies a comma-separated list of media ranges (with optional parameters) as defined by [RFC7231], Section 5.3.2. The Accept-Put header, in effect, uses the same syntax as the HTTP Accept header minus the optional accept-params BNF production, since the latter does not apply to Accept-Put.
The Accept-Put header specifies a comma-separated list of media ranges (with optional parameters) as defined by [RFC9110], Section 12.5.1. The Accept-Put header, in effect, uses the same syntax as the HTTP Accept header.
The presence of the Accept-Put header in response to any method is an implicit indication that PUT is allowed on the resource identified by the request URI. The presence of a specific document format in this header indicates that that specific format is allowed on PUT requests to the resource identified by the request URI.
The presence of the Accept-Put header in response to any method is an implicit indication that PUT is allowed on the resource identified by the target URI. The presence of a specific document format in this header indicates that that specific format is allowed on PUT requests to the resource identified by the target URI.
IANA Registration Template:
-The Accept-Put response header must be added to the permanent registry (see [RFC3864]).
The Accept-Put response header must be added to the permanent registry (see [RFC9110]).
While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.
-Implementations are subject to the same security considerations that are found in HTTP/1.1 [RFC7230] and [RFC7231].
+Implementations are subject to the same security considerations that are found in HTTP Semantics [RFC9110] and HTTP/1.1 [RFC9112].
Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to restrict untrusted requests. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.
@@ -1339,7 +1335,7 @@Content-Type in messages with payload.Content-Type in messages with content.