Write methods as requirements #304
Conversation
|
BTW, in the back of my head, I had a comment in the back of my head that @timbl had expressed similar sentiments, and I finally found a comment to the LDP comments list:
|
|
A point of clarification: must all resources be read/write? Must only a subset of resources be read/write? Must there be at least one resource that is read/write? |
|
A big +1 to the clear intent behind this issue, although I'd tend to be a bit more nuanced in my support of the specifics - e.g., if I wanted to offer a "Wayback-machine Pod service", I may not want to offer any DELETE functionality whatsoever. |
|
This PR should respond to #39 (comment) . |
|
@acoburn & @pmcb55 I think that's covered by the sentence in the current spec that says:
That is, the requirement is on the server as a whole, if that particular target resource doesn't support a certain method, then it is legitimate to respond with a @csarven I thought that I did, what do you feel I didn't touch upon? I'm concerned that if we do not emphasize the rw nature of Solid, we could end up as the early Web, where everything were designed read-write but that aspect was not appreciated by a lot of people, and therefore browsers were designed read-only. |
|
This is a source of pain, suffering and untold hours of madness while writing tests... I have added another commit, now to the security considerations, hopefully addressing the concern that deployments may want to restrict certain operations entirely. |
csarven
left a comment
There was a problem hiding this comment.
Going to quote myself from #39 (comment) because it requests clarity as to why the bar must be higher. Given two different ways to implement (one server with write capabilities and other not), and that they can both return 405. Some servers will never need to allow write requests (and so blocking immediately with 405) - e.g., archives, backups, audit logs, provenance records, memento resources.. - meanwhile still implementing an authorization system that would only need to allow read operations for specific resources to specific agents/clients:
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.
Co-authored-by: Sarven Capadisli <info@csarven.ca>
Co-authored-by: Sarven Capadisli <info@csarven.ca>
Co-authored-by: Sarven Capadisli <info@csarven.ca>
| <h3 property="schema:name">Writing Resources</h3> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
| <p>When a server supports the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] this specification imposes the following requirements: [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p> | ||
| <p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p> |
There was a problem hiding this comment.
| <p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p> | |
| <p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code>, and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p> |
There was a problem hiding this comment.
I think I shall leave it to native English speakers to debate that comma. :-)
|
This PR was discussed in this meeting: https://github.com/solid/specification/blob/main/meetings/2021-11-03.md#write-methods-as-requirements . In summary: The underlying argument to require all Solid servers to have write-capability was due to a particular testing architecture/software requiring changes that would be too much of a task to have it ready for the 0.9 release of the Protocol specification. While there was mutual understanding that specs, as opposed to testing software, drives the requirements, the release of a spec version for "pragmatic" reasons was deemed to be an exception by some of the editors. The possibility to allow server implementations where their sole purpose is to be read-only without having any code paths for write operations and still be acknowledged to be part of the Solid ecosystem did not receive legitimate response or deemed to have merit by some of the editors. No resolution was recorded for the 1.0 release. For the record, I'm not satisfied with the arguments given to dismiss read-only servers. As mentioned, there are legitimate reasons to require write but not at the expense of dismissing use cases where only read is required. The merge of this PR also goes contrary to enabling an inclusive and equitable ecosystem. The Solid Protocol mentions how we use the Ethical Web Principles to orient ourselves. As is stands, the first sentence in the Introduction of the Solid Protocol:
I will follow with a PR to reverse this for the 1.0 release, and hope that specific testing software and/or lack of resources to develop them, does not dictate the behaviour of the Solid ecosystem by that point. |
|
As discussed in Editors meeting https://github.com/solid/specification/blob/main/meetings/2021-11-10.md#write-methods-as-requirements , it turns out that this PR was accidentally merged. The agreement was to have this as is for 0.9 - given that there is some approval - but that we'll revisit for 1.0. |
The current spec does not require write methods to be implement. I disagree with this, as it introduces doubt as to what a Solid server really is. Solid should be very clear about that it is read-write. Without write, there's no social interaction, no setting of authorization, no notifications. That is not to say that a read-only server isn't a part of the ecosystem, it is, but there's so little that is Solid-specific in a read-only scenario that it doesn't make sense IMHO to call it a Solid server. It'd still be a Web server, it'd still serve up resources that can be used on the Web and into Solid apps. It just isn't a Solid server.
Therefore, I suggest we make the write methods
PUT,POST,PATCHandDELETErequired. If something does not implement all of these, it will not be a fully compliant Solid server, though it may be useful.