Tighten consistency requirements for resource types #341
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -665,6 +665,22 @@ <h3 property="schema:name">Resource Type Heuristics</h3> | |
|
|
||
| <p><span about="" id="server-post-uri-assignment" rel="spec:requirement" resource="#server-post-uri-assignment"><span property="spec:statement">When a successful <code>POST</code> request creates a resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> assign a URI to that resource.</span></span> <span about="" id="server-slug-uri-assignment" rel="spec:requirement" resource="#server-slug-uri-assignment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> allow clients to suggest the URI of a resource created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-rfc5023">RFC5023</a></cite>].</span></span></p> | ||
|
|
||
| <p> | ||
| <span about="" id="server-ensure-consistency" rel="spec:requirement" resource="#server-ensure-consistency"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> only accept requests where there is consistency between the path ending (<a href="#uri-slash-semantics">URI Slash Semantics</a>), any HTTP <code>Link</code> headers with <code>rel="type"</code> and the media type given in the <code>Content-Type</code> header of the request.</span></span> | ||
| <span about="" id="server-reject-inconsistency" rel="spec:requirement" resource="#server-reject-inconsistency"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> reject inconsistent requests using a <code>415</code> (for media type inconsistency) or <code>409</code> (for all other inconsistencies) status code as per Section 4.3.4 of [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> | ||
|
There was a problem hiding this comment. Isn't this repeating RFC 7231? It is already covered in #http-server. There was a problem hiding this comment. To some extent, it is, but there is considerable room for interpretation since HTTP isn't entirely consistent itself at this point, as the discussion between @RubenVerborgh and myself shows. Therefore, it needs to be explicit. |
||
| <span about="" id="server-existing-type-inconsistency" rel="spec:requirement" resource="#server-existing-type-inconsistency"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> receives a request that attempts to change the resource type, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> verify that the resource type of the request is compatible with the current resource type and reject the requests using a <code>409</code> status code if it is not.</span></span> | ||
|
There was a problem hiding this comment. For this to be effective, the resource types need to be a normative requirement. There was a problem hiding this comment. I disagree, will discuss in #301. |
||
| [<a href="https://github.com/solid/specification/issues/301" rel="cito:citesAsSourceDocument">Source</a>] | ||
| </p> | ||
|
|
||
| <div class="note" id="resource-type-interpretation" inlist="" rel="schema:hasPart" resource="#resource-type-interpretation"> | ||
| <h4 property="schema:name"><span>Note</span>: Interpretation of Resource Types</h4> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
| <p> | ||
| Clients and servers may indicate resource types using a HTTP <code>Link</code> headers with <code>rel="type"</code>, but should be aware that they come with assumptions as to what media types can be associated with them. In particular, Solid requires containers to be represented by an <em>RDF Document</em>, which again requires an appropriate RDF serialization with a corresponding media type for consistency. Other media types may have similar consistency requirements. | ||
| </p> | ||
| </div> | ||
| </div> | ||
|
|
||
| <div class="note" id="uri-allocation" inlist="" rel="schema:hasPart" resource="#uri-allocation"> | ||
| <h4 property="schema:name"><span>Note</span>: URI Allocation</h4> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will this be tested without knowledge of specific required types? It appears to introduce unnecessary variance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not understand how it introduces variance, to the contrary, it is a constraint...
It is clear that it cannot be tested in the general case, there's an open world out there, but we do have knowledge of some specific resource types, the LDP ones, and we can test them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is introducing a (vague) requirement that depends on variable resource typing. Not only there is no useful testing for the general case but the specific testing is very limited. As mentioned, there is currently only one place where LDP's specific type is used - and that's being blown out of proportion as it seems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that you have inspected the existing tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you refer to the tests corresponding to the requirements in the SP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at present, but if this was merged, I could.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.