-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which LDP features are required by Solid #39
Comments
My suggestion is to make I would also make |
Need to be clear on "support". Checking for support can be a grey area in that if |
Just so that we document some reasons: an overarching reason as to why methods like We need the servers at |
I tentatively suggest the following which extends LDP: Generally:
Specifically: Intention for server-side containment management SHOULD be communicated through Servers MAY use both the
is equivalent to:
Clients intending to create both the resource and containment triples for a URI eg.
Second step as example:
|
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. |
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 Re:
I understand the context in which you mean that but I was going with text like the following or other client hints:
Clients certainly make their intentions clear to the server. They acknowledge the purpose and effects of using the interaction models eg. |
@csarven - How about -- Servers SHOULD NOT allow triples within (Side note: affect, not effect.) |
Also "should not allow" is vague: should they reject it? Or ignore it? Let's be very specific. |
That's in the LDP spec: https://www.w3.org/TR/ldp/#dfn-ldp-server-managed-triples |
@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 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. |
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.
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. |
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
andOPTIONS
.At what level of support does a Solid server implementation need to implement
POST
,PUT
,DELETE
andPATCH
? It is worth noting that, viaOPTIONS
, a client can easily discover which methods a server supports for a given resource (via theAllow
response header). It is also worth noting thatPATCH
is, effectively, an optimization ofPUT
.The text was updated successfully, but these errors were encountered: