Contradicting requirements on contained resource metadata

[damooo]

Following two statements contradict each other.

Req1

Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.

Req2

Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container’s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code. [Source]

First one requires us to update contained resource metadata statements, when POST targets a container with representation of to be created resource.

Second one forbids updating them when POST targets a container.

I understand that intention in second statement is to disallow them in case of POST in representation of to be created container, but not request target. But statement generalizes over methods on request-target, and representation-update operations.

[damooo]

Request to correct me if i am missing something obvious

[csarven]

First one requires us to update contained resource metadata statements, when POST targets a container with representation of to be created resource.

#server-contained-resource-metadata intends that the server should authoritatively materialise the resource metadata about contained resources. It does not require servers to accept and preserve the sender's statements about contained resource metadata.

Second one forbids updating them when POST targets a container.

I understand that intention in second statement is to disallow them in case of POST in representation of to be created container, but not request target. But statement generalizes over methods on request-target, and representation-update operations.

#server-protect-contained-resource-metadata intends that the target of the HTTP request is the container resource.

#server-protect-contained-resource-metadata intends a constraint on the request semantics of POST (to "perform resource-specific processing on the request payload"), targeting a container. It does not describe the processing instructions for payloads containing resource metadata about "to be created" resource. In essence, the server can accept the POST request while ignoring sender's statements about contained resource metadata.

---

There is a related background in #298 (comment) where I mentioned:

Updating container's description (as opposed to the side-effect of processing) with POST is unspecified. 409 can't even occur with the current spec. A test might at best reveal that there is no 409 possibility.

It means that when a POST request targets a container, the request semantics is about appending to the container - in effect creating a new resource in the targetted container. It is not about updating the description of the container (besides effectively adding a containment statement and server including resource metadata about the created resource.)