Link Headers for Container POST Responses

[no-reply]

In Container#post we choose to give the created resource as the response body. When doing this, we also return the headers for the new resource as well.

LDP 5.2.1.4 requires returning a Container Link header for all responses in requests to containers. The current behavior is in contravention of this.

Should POST responses be altered to include the Link header as required by 5.2.1.4? If so, should they also continue to return the ETag for the created resource?

The examples in the spec vary. Example 11/12 shows the container header; Example 15/16 do not. None of the examples in LDP Primer show a container header.

[mjsuhonos]

What is the potential negative impact of including a Link header for POST responses for Containers? Would continuing to include the ETag header conflict with this in any way?

I suspect Example 15/16 may have been created before LDP 5.2.1.4 or is in error, since it returns a Link header type of RDFSource, not IndirectContainer (which is still a type of RDFSource); ie. correct as per LDP 4.2.1.4, but not as per LDP 5.2.1.4.

My interpretation of the requirements for POST responses to Containers would be that Link headers SHOULD be included for both Resource (4.2.1.4) and the type of Container (5.2.1.4), as suggested by the MAY requirement in 5.2.1.4.

However, given that a LDPC is by definition a type of LDPR, it could be argued that providing a single Link header for the type of Container (as per 5.2.1.4) would be sufficient to satisfy the "LDP support advertisement" of 4.2.1.4.

[no-reply]

I've posted a message about this to the LDPNext CG's list: https://lists.w3.org/Archives/Public/public-ldpnext/2016Feb/0006.html

Speaking directly to @mjsuhonos's comments:

What is the potential negative impact of including a Link header for POST responses for Containers? Would continuing to include the ETag header conflict with this in any way?

I can't find any explicit requirement that headers pertain uniformly to one resource, but it seems odd to include Link: ;rel=type headers that describe the POST target and an ETag that describes the created resource.

RFC 2616 says in Sec. 6.2 only that "These header fields give information about the server and about further access to the resource identified by the Request-URI."

My interpretation of the requirements for POST responses to Containers would be that Link headers SHOULD be included for both Resource (4.2.1.4) and the type of Container (5.2.1.4), as suggested by the MAY requirement in 5.2.1.4. However, given that a LDPC is by definition a type of LDPR, it could be argued that providing a single Link header for the type of Container (as per 5.2.1.4) would be sufficient to satisfy the "LDP support advertisement" of 4.2.1.4.

We have logic handling the inclusion of Resource, RDFSource, NonRDFSource, and Container headers as appropriate. We include ldp:Resource for all LDP responses, ldp:RDFSource for all RDFSources (including Containers), and the container type.

[no-reply]

Note that RDF 2616 sec. 10.2.2 addresses the ETag issue directly:

A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

[no-reply]

In lieu of any response from original LDP WG members, I'm resolving to leave this behavior as is: Link header match the entity represented in the body

It seems like any client sending POST requests will already know that the resource is a container, this would be further confirmed by the 201 response. If anyone knows of a client relying on the Link headers returning as described in 5.2.1.4 for successful POSTs, they are welcome to reopen the issue.