Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Tighten consistency requirements for resource types #341

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Tighten consistency requirements for resource types #341

Changes from 6 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
39da028
Add initial consistency requirement
kjetilk Oct 29, 2021
cfa3e24
Suggest 409 for now
kjetilk Oct 29, 2021
cf35d33
Add #301 as source
kjetilk Oct 29, 2021
928cfc9
Improve around status code
kjetilk Oct 29, 2021
ee05279
Add note to further explain
kjetilk Oct 29, 2021
afa8cdc
Proposed wording for consistence with existing resources
kjetilk Oct 29, 2021
c2ce563
Remove a must
kjetilk Nov 1, 2021
c6f422b
Add comments on status code per @RubenVerborgh's suggestion
kjetilk Nov 1, 2021
c325873
Fix typos
kjetilk Nov 1, 2021
c17376c
add whitespace
kjetilk Nov 1, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

@csarven csarven Nov 16, 2021 •
edited
Loading

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?

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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-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>409</code> or <code>415</code> status code as per Section 4.3.4 of [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span>
kjetilk marked this conversation as resolved.
Show resolved Hide resolved
<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> recieves a request that attempts to change the resource type, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> must 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>
kjetilk marked this conversation as resolved.
Show resolved Hide resolved
[<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 a <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.
RubenVerborgh marked this conversation as resolved.
Show resolved Hide resolved
</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">
Expand Down