Tighten consistency requirements for resource types #341

kjetilk · 2021-10-29T22:55:59Z

With the sound of the deadline of the milestone approaching with rising pitch, I decided to draft what I think is coming out of #301. There doesn't seem to be significant opposition to most of this given the test results, with the possible exception of the status code. I put 409 in anyway. We can conclude that debate in #301.

The PR should address both my initial concern, and @langsamu's first concern of changing resource types. The text isn't very extensive, and does not cover it in as much detail as we did on the issue, but I think we can enforce this by encoding the status codes in tests.

protocol.html

RubenVerborgh

LGTM; I'm still in favor of 400, but let's settle that in #301 indeed.

protocol.html

Co-authored-by: Aaron Coburn <[email protected]>

kjetilk

Responses to @RubenVerborgh . The github workflow isn't very handy at these short things :-)

protocol.html

dmitrizagidulin

👍

csarven

I like the idea of introducing information on consistency. However, I do not think that we have (significant) normative requirements in SP to specify this just yet. We should get those up to speed (in either direction) to know what consistency will be, especially with the role of type link relation. Details: #301 (comment)

csarven · 2021-11-16T10:35:22Z

protocol.html

@@ -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>


How will this be tested without knowledge of specific required types? It appears to introduce unnecessary variance.

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.

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.

I assume that you have inspected the existing tests?

Can you refer to the tests corresponding to the requirements in the SP?

Not at present, but if this was merged, I could.

Suggested change

Servers MUST 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.

Servers MUST 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.

csarven · 2021-11-16T10:42:00Z

protocol.html

@@ -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>


Isn't this repeating RFC 7231? It is already covered in #http-server.

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.

#301 (comment)

csarven · 2021-11-16T10:43:10Z

protocol.html

+		  <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>
+		    <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>


For this to be effective, the resource types need to be a normative requirement.

I disagree, will discuss in #301.

kjetilk added 6 commits October 29, 2021 23:45

Add initial consistency requirement

39da028

Suggest 409 for now

cfa3e24

Add #301 as source

cf35d33

Improve around status code

928cfc9

Add note to further explain

ee05279

Proposed wording for consistence with existing resources

afa8cdc

kjetilk self-assigned this Oct 29, 2021

kjetilk added doc: Protocol topic: resource access labels Oct 29, 2021

kjetilk added this to the Release 0.9 milestone Oct 29, 2021

kjetilk linked an issue Oct 29, 2021 that may be closed by this pull request

Slash semantics and conflicting requests on resource creation #301

Open

kjetilk requested review from RubenVerborgh and csarven October 29, 2021 22:59

acoburn reviewed Oct 29, 2021

View reviewed changes

protocol.html Outdated Show resolved Hide resolved

RubenVerborgh approved these changes Oct 30, 2021

View reviewed changes

protocol.html Outdated Show resolved Hide resolved

protocol.html Outdated Show resolved Hide resolved

protocol.html Outdated Show resolved Hide resolved

Remove a must

c2ce563

Co-authored-by: Aaron Coburn <[email protected]>

kjetilk commented Nov 1, 2021

View reviewed changes

protocol.html Outdated Show resolved Hide resolved

protocol.html Outdated Show resolved Hide resolved

kjetilk added 3 commits November 1, 2021 11:13

Add comments on status code per @RubenVerborgh's suggestion

c6f422b

Fix typos

c325873

add whitespace

c17376c

kjetilk requested a review from a team November 1, 2021 16:48

dmitrizagidulin approved these changes Nov 10, 2021

View reviewed changes

csarven requested changes Nov 16, 2021

View reviewed changes

kjetilk removed this from the Release 0.9 milestone Nov 16, 2021

csarven force-pushed the main branch from 27f847b to c6c4842 Compare December 18, 2023 13:30

csarven force-pushed the main branch from e121e05 to 4cfdd90 Compare May 30, 2024 08:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tighten consistency requirements for resource types #341

Tighten consistency requirements for resource types #341

kjetilk commented Oct 29, 2021

RubenVerborgh left a comment

kjetilk left a comment

dmitrizagidulin left a comment

csarven left a comment

csarven Nov 16, 2021

kjetilk Nov 16, 2021

csarven Nov 16, 2021

kjetilk Nov 16, 2021

csarven Nov 16, 2021 •

edited

Loading

kjetilk Nov 16, 2021

TallTed Nov 17, 2021

csarven Nov 16, 2021

kjetilk Nov 16, 2021

csarven Nov 16, 2021

csarven Nov 16, 2021

kjetilk Nov 16, 2021

Tighten consistency requirements for resource types #341

Are you sure you want to change the base?

Tighten consistency requirements for resource types #341

Conversation

kjetilk commented Oct 29, 2021

RubenVerborgh left a comment

Choose a reason for hiding this comment

kjetilk left a comment

Choose a reason for hiding this comment

dmitrizagidulin left a comment

Choose a reason for hiding this comment

csarven left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

csarven Nov 16, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

csarven Nov 16, 2021 •

edited

Loading