Node-solid-server: Support LDPC via HTTP PUT

Created on 19 Feb 2019  路  6Comments  路  Source: solid/node-solid-server

Derived from issue https://github.com/solid/node-solid-server/issues/1107

Support HTTP PUT + Link with LDPC, or more specifically the types currently supported (like LDP-BC).

Most helpful comment

Fwiw, I do think this is a useful feature to implement.
(In fact, I did go so far as to implement it -- but the PR stalled due to an argument about PUT semantics.)

All 6 comments

Is this really a bug? Digging in LDP spec [1], I find:

  • 5.2.3.1 LDP clients should create member resources by submitting a representation as the entity body of the HTTP POST to a known LDPC. If the resource was created successfully, LDP servers must respond with status code 201 (Created) and the Location header set to the new resource鈥檚 URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response.

    • noting that a contained container is also a contained resource.
  • Per [RFC7231], this HTTP method is optional and this specification does not require LDP servers to support it. When a LDP server supports this method, this specification imposes the following new requirements for LDPCs.

    • section 5.2.4
    • this suggests to me that depending on PUT to create a container cannot be relied upon

[1] https://www.w3.org/TR/2015/REC-ldp-20150226/

Generally, I'm also thinking that if using PUT to create a container (or any resource), there's no way for that container (resource) to be created as a member of some container. The spec explicitly ~prohibits~ strongly discourages using PUT (e.g. subsequently) to modify containment properties (sect 5.2.4.1).

I would suggest that in this case, a "409 Conflict" response would be appropriate when attempting a PUT to a non-existent resource with a container type specified.

Sorry for the confusion, but I raised this as a feature, not a bug :) In any case, you're right about modifying containment triples. It is unclear to me right now why POST to create would be okay but not PUT. Is it because the parent container is not necessarily "aware" of the new container being created?

I think we can close this issue if PUT is a no go. Server already responds with 409 IIRC. What do you think?

@csarven, re:

It is unclear to me right now why POST to create would be okay but not PUT.

Assuming that you always want a resource to be created within some container, PUT doesn't provide any standard way to do that (that I can see). I suppose one _might_ use a link relation or similar to indicate a container to which the resource is added. My perception is that POST allows the server enough control to ensure things are kept consistent.

I don't have a strong view on closing or not - I'm still new to Solid and its community. If solid-server already responds 409, I can't see much call to keep this open, but YMMV.

Nothing to act on right now I think, so okay to close. If our viewpoint changes, we can revisit.

Fwiw, I do think this is a useful feature to implement.
(In fact, I did go so far as to implement it -- but the PR stalled due to an argument about PUT semantics.)

@dmitrizagidulin I find the issue of POST vs PUT for containers and tracking/handling containment triples is too much implementation plumbing. I don't see a technical issue with either, eg. surely a server can be capable of handling PUT container just as it can with POST, regardless of where they're created. In any case, I'm sure people have thought this through, so defaulting to that for now. I can understand that handling the non-new containers (modification) can get hairy. I totally welcome the possibility to use PUT to create containers, if anyone thinks we should revisit this! LDP spec says SHOULD, not MUST... but any way. Sorry that I missed your PR earlier.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

RubenVerborgh picture RubenVerborgh  路  4Comments

akuckartz picture akuckartz  路  6Comments

kjetilk picture kjetilk  路  7Comments

melvincarvalho picture melvincarvalho  路  4Comments

rubensworks picture rubensworks  路  4Comments