Tighten consistency requirements for resource types

[kjetilk]

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.

[RubenVerborgh]

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

[kjetilk]

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

[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]

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

[kjetilk]

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.

[csarven]

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.

[kjetilk]

I assume that you have inspected the existing tests?

[csarven]

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

[kjetilk]

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

[TallTed]

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>

[csarven]

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

[kjetilk]

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.

[csarven]

#301 (comment)

[csarven]

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

[kjetilk]

I disagree, will discuss in #301.