Which LDP features are required by Solid

Section 2.2 of the Solid specification requires (MUST) conformance with the LDP specification. The LDP specification, however, lists many features as optional.

LDP requires that a server support GET, HEAD and OPTIONS.

At what level of support does a Solid server implementation need to implement POST, PUT, DELETE and PATCH? It is worth noting that, via OPTIONS, a client can easily discover which methods a server supports for a given resource (via the Allow response header). It is also worth noting that PATCH is, effectively, an optimization of PUT.

My suggestion is to make POST, PUT, DELETE, and PATCH all MUST for Solid; except that of course a server is free to only offer read-only resources, in which case it would not need to support them.

I would also make PATCH a MUST because of concurrent editing use cases.

Need to be clear on "support". Checking for support can be a grey area in that if MUST is given, server's capability needs to be essentially testable. Whether they offer resources as read-only is a separate case and we can incorporate that in the test. For example, the test can offer a check against read-only resources, and when tested as such, all MUSTs would be expected to return a 405 and so it will pass the test, and fail otherwise.

Just so that we document some reasons: an overarching reason as to why methods like POST, PUT, DELETE and PATCH should be required (at some level) for servers to support is that the writing - creating, deleting, updating - capability is central to the Solid ecosystem.

We need the servers at MUST to enable an even ground for clients. I don't think SHOULD will cut it.

I tentatively suggest the following which extends LDP:

Generally:

GET: ...
HEAD: ...
OPTIONS: ...
POST: creating, appending, containment management
PUT: creating, replacing
PATCH: creating, updating
DELETE: remove, containment management

Specifically:

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

Servers MAY use both the Slug and the Link header values in POST requests to determine hints for containment management. In the following example, the server uses the slashes in Slug as a separator for nested containers based on the interaction model(s) as specified in the Link header.

POST /
Slug: foo/bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/

is equivalent to:

POST /
Slug: foo/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/

POST /foo/
Slug: bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/

GET /foo/

Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

<>
  ldp:contains <http://example.org/foo/bar/> .

Clients intending to create both the resource and containment triples for a URI eg. http://example.org/foo/bar/baz should:

POST to create container(s) eg. http://example.org/foo/ contains http://example.org/foo/bar/
POST to create resource in container eg. http://example.org/foo/bar/ contains http://example.org/foo/bar/baz

Second step as example:

POST /foo/bar/
Slug: baz
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"

Location: http://example.org/foo/bar/baz

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

I think the terminology is slightly confusing. Container management is something solely done by the server, and not a concern for the client (not even communicating an intention). And clients should be able to create/modify/delete resources via the usual verbs - PUT, POST, DELETE.

I think the terminology is slightly confusing. Container management is something solely done by the server, and not a concern for the client (not even communicating an intention).

Taking LDP's "server-managed triples" as given. The attempt was to clarify the affordances of those methods in LDP. Is this more clear:

Clients SHOULD use POST and DELETE to apply LDP's interaction models on resources. Servers SHOULD NOT allow PUT and PATCH to effect server-managed triples.

Re:

not even communicating an intention

I understand the context in which you mean that but I was going with text like the following or other client hints:

LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s)

Clients certainly make their intentions clear to the server. They acknowledge the purpose and effects of using the interaction models eg. POST to a LDPC will result in...

@csarven

@csarven - How about --

Servers SHOULD NOT allow triples within PUT and PATCH payloads to affect server-managed triples.

(Side note: affect, not effect.)

~~We'd need a definition of "server-managed triples" (and maybe a different term).~~

Also "should not allow" is vague: should they reject it? Or ignore it?

Let's be very specific.

We'd need a definition of "server-managed triples" (and maybe a different term).

That's in the LDP spec: https://www.w3.org/TR/ldp/#dfn-ldp-server-managed-triples

If I interprete this correctly, the implication of

Servers SHOULD NOT allow PUT and PATCH to effect server-managed triples.

is that orphans are ok, #97 and the system is not strictly hierarchical, #98 .

Thus, I think we need to settle those high-level design issues first.

@TallTed

@TallTed Right! :)

@RubenVerborgh It was partly derived from 5.2.4.1 for the purpose of moving the discussion forward. How about an alternative:

Clients SHOULD use POST and DELETE to apply interaction models on LDPR. Servers SHOULD NOT allow PUT and PATCH to affect LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

Note: sticking to only containment triples.

@kjetilk Sure, let's move those forward but not go too high. Use Cases would be the ideal level. I agree that 97 and 98 will help to frame it better.

Ok, while I agree with LDP section 5.2.4.1 "LDP servers should not allow HTTP PUT to update a LDPC’s containment triples", we have a strong disagreement on what the text actually means.

Creating containers via PUT, POST or PATCH does not update their containment triples directly. The updating of containment triples is done solely by the server, as a side effect.

Look, to put it simply, there is absolutely no reason not to allow container creation via PUT. Part of the reason it was brought up as a feature request is because messing with POST + slug for creating containers has historically resulted in a lot fo developer confusion.

Creating containers via PUT, POST or PATCH does not update their containment triples directly. The updating of containment triples is done solely by the server, as a side effect.

Yes, LDP's notion of "server-managed triples" was already covered. Methods are used to issue requests as a whole, including the side effects as mentioned in RFC. A request is not confined to what's in representation body. In LDP's case, it includes server-managed triples and server-specific constraints.

there is absolutely no reason not to allow container creation via PUT.

Okay but that wasn't proposed.

Okay but that wasn't proposed

Ok whew :) All good then

Actually, I'm not quite happy here... It see no record of consensus regarding whether the write operations are required, and now Solid only has language to the effect of "When the server supports".

I think a Solid server without write methods make zero sense, that's just a Web Server, with a big but largely unused authz system. If you'd like to use WAC for a read-only site, you can perfectly well do that without referencing the protocol spec.

I'd like to reopen this to discuss whether write operations should be a MUST. It would amount to change only one sentence.

The original PR for it in fact used MUST. I made that editorial call since there was rough consensus in this thread. Aside: The issue was stale for close to a year, and if I hadn't pushed the PR forward, who knows how long it would've been until we had a section on "reading and writing resources". In the PR however (see thread: https://github.com/solid/specification/pull/188/files/21e5c395be489f423874864a4a7440b57fdf6ad1#r451798742 ) it got changed to "When.." and mentioned 405. Looking back, perhaps what was originally intended got a bit muddied there.

While I still think that servers MUST implement PUT, POST, PATCH, DELETE, I can also see that there is room for servers only implementing GET, HEAD, OPTIONS and participating in the ecosystem. I don't see significant or practical difference between a server implementing the PPPD and GHO methods but configured by its owner to return 405 on PPPD, with a server implementing only GHO and returning 405 for PPPD. GHO-only is a low bar entry and supports sufficient use cases, quickly implemented, run on environments with minimal resources, and can always be upgraded to support PPPD.

I think authorization system is not particularly relevant here. The system doesn't need to resort to the authorization system to disallow write operations. That would only cover user/client level access control with 403, not 405.

I'm sorry, I didn't intend to suggest it wasn't appropriate to close the issue in the absence of comments. That's perfectly OK, but I still want to change it now. I guess I should have opened a new issue instead. I'll do that.

Navigation Menu

Which LDP features are required by Solid #39

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Which LDP features are required by Solid #39

Description

Activity

RubenVerborgh commented on Sep 19, 2019

csarven commented on Oct 3, 2019

csarven commented on Oct 3, 2019

csarven commented on Oct 21, 2019

dmitrizagidulin commented on Oct 23, 2019

csarven commented on Oct 23, 2019

TallTed commented on Oct 23, 2019

RubenVerborgh commented on Oct 23, 2019

kjetilk commented on Oct 23, 2019

kjetilk commented on Oct 23, 2019

csarven commented on Oct 24, 2019

dmitrizagidulin commented on Oct 24, 2019

csarven commented on Oct 24, 2019

dmitrizagidulin commented on Oct 24, 2019

kjetilk commented on Aug 27, 2021

csarven commented on Aug 29, 2021

kjetilk commented on Aug 30, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions