Skip to content

Support creating a Container using PUT #1465

Closed

Description

@Vinnl

According to the Solid spec:

Servers MUST create a container with URI path ending /{id}/ in container / for requests including the HTTP Link header with rel="type" targeting a valid LDP container type.

However, when I send a PUT request to a Container URL with a Link header <http://www.w3.org/ns/ldp#BasicContainer>; rel="type", NSS responds with:

Can't write file: PUT not supported on containers, use POST instead

Activity

  1. bourgeoa commented on Aug 17, 2020

    @bourgeoa
    Member

    This is the new spec. Does it support also creation of missing containers with PUT ?

  2. Vinnl commented on Aug 17, 2020

    @Vinnl
    ContributorAuthor

    If you mean "would the workaround of creating a dummy file inside the Container and then deleting it again" still work, then yes:

    Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT, POST and PATCH requests.

    And yes, that's what I'm currently doing for NSS specifically. This issue is linked from a comment there so I know when I can remove that code :)

  3. bourgeoa commented on Aug 17, 2020

    @bourgeoa
    Member

    No, I was meaning : if the container URI contains missing container do you create the container and all missing ones or do you return an error.

  4. csarven commented on Aug 17, 2020

    @csarven
    Member

    @Vinnl The requirement you've originally quoted in this issue is in context of POST. I can update the spec paragraph to clarify if that helps.

    NSS doesn't currently support PUT to create a container - only as side-effect when creating a non-container resource. Background/proposal to support creating containers with PUT: #1108 and #513

    Spec going forward clarifies slash semantics and hierarchical containment, PUT /path/to/container/ will create all required intermediate containers. Client doesn't need include the Link header with a valid LDP container type for PUT. Server is not expected to observe it.

  5. bourgeoa commented on Aug 17, 2020

    @bourgeoa
    Member

    @csarven So if I read correctly your comment : Why the new spec does not state that PUT to a container URI (ending with /) is not allowed and should return error (405 or 400) ?

  6. csarven commented on Aug 17, 2020

    @csarven
    Member

    @bourgeoa Can you please rephrase your question or comment?

    It would be great if NSS can accept requests with PUT to create a container, as well as intermediate containers if they don't exist.

    Note slash semantics requirement:

    The slash character in the URI path indicates hierarchical relationship segments, and enables relative referencing. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource.

    NSS may also do the following:

    Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource.

  7. bourgeoa commented on Aug 18, 2020

    @bourgeoa
    Member

    @csarven
    Your rephrase of my comment is not at all what I meant. May be I was wrong, reading the spec and comments I inferred that PUT for a container was not allowed, if that was correct (not sure reading the spec) was asking if it could be more affirmative.

    I know and understand building spec is difficult.
    Here I am not sure of the final result. I am not asking to change it, just to understand it.

  8. csarven commented on Aug 18, 2020

    @csarven
    Member

    @bourgeoa Why would I rephrase your comment? I asked you to rephrase what you wrote because it is not at all clear if you are asking a question or making a comment. What I wrote was entirely about the state of NSS and the direction it can take based on the upcoming spec.

    If there is anything that's unclear in the spec, please quote the part that we can clarify or help with with respect to NSS. Like I said:

    NSS should support PUT to create container - we've known for years that it doesn't - however, going forward, if it can't or even for any specific container (for any reason), it is within its right.

  9. bourgeoa commented on Aug 18, 2020

    @bourgeoa
    Member

    @csarven
    Ok I think the problem arise because I in the same time spoke of NSS and the spec direction.

    spec direction :

    • you wrote NSS should support PUT to create container is it a MUST in the new spec ?
    • in the spec writing resources : When a server supports the HTTP PUT, POSTandPATCH methods does it imply that a server MAY support for some resource and not for others, like when you write if it can't or even for any specific container (for any reason), it is within its right. I don't know where to find that in the spec

    Sorry if I miss something. Reading spec are really difficult because container is a resource. May I suggest to clarify with non container resource and container. I suppose mostly in the writing resource paragraph.

  10. added a commit that references this issue on Nov 11, 2020
  11. ThisIsMissEm commented on Mar 28, 2022

    @ThisIsMissEm

    @bourgeoa I think the spec is now very clear on all matters talked about above: https://solidproject.org/TR/protocol#writing-resources

    Writing Resources

    Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [Source] [Source]

    Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests. [Source]

    Might be worth looking into whether we can make NSS support PUT for Containers, that way we can clean up some code that's only used when talking with NSS instances (I'm assuming it'd be as simple as adding a router.put rule alongside a router.post or something)

    (note: this isn't a high priority from the DevTools Team side at Inrupt, I just was going through our code, noticed the comment and was curious as to if it still held true, hence now commenting.

  12. ThisIsMissEm commented on Mar 28, 2022

    @ThisIsMissEm

    But maybe this was actually closed by the work in #1557 — I'm not sure?

  13. bourgeoa commented on Mar 28, 2022

    @bourgeoa
    Member

    Yes it was closed with #1557

  14. ThisIsMissEm commented on Mar 28, 2022

    @ThisIsMissEm

    Wonderful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions