can LDP let a client know that it does not support PUT on creation?

[bblfish]

I have not yet implemented PUT to create resources on my Solid server, in part because my server has restrictions on the type of URLs that could be used for a PUT and there is no way to express that to the client. (see comment on issue 44: the server does not allow . in paths, because it uses those for metadata and content negotiation on the file system.)

IT would be useful to be able to express that PUT to create is not allowed by a server, but I can't see that this is possible in LDP as PUT on a container (especially indirect containers) is it seems acceptable... So that PUT would appear in the Allow: header on a Container there, but would not mean that one can use PUT to create resources.

Is this another user case for a Link constrainedBy ontology?

[kjetilk]

Most certainly, the server would respond with a 403 whenever the proposed resource name is no acceptable to it.

So, the way I understand this issue is that you want to have a way for the server to communicate that it will not support the PUT method on any resource. Is that the idea?

[kjetilk]

Also, in that case, when you're not allowing the method at all, you would always respond with 405 to a PUT request.

[bblfish]

So, the way I understand this issue is that you want to have a way for the server to communicate that it will not support the PUT method on any resource. Is that the idea?

Yes. PUT to create is not so much an action on one resource, as a capability of the server I think, as it covers a whole range of resources, including potentially creating new containers, etc...

There are two things:

1. I'd like to communicate to the client that I don't support PUT to create a resource - I am not sure how to do that at present. The simple answer is to not put PUT in the Allow header on a container, but other servers may have PUT in the Allow header, not because they allow resources to be created with PUT, but because they want to express that the container can be updated with a PUT -- which I find somewhat dubious: it may be better if the data on a Direct or Indirect Container be in a separate resource that gets imported to the basic container (a bit like the :imports use case for WAC).
2. When I later do support PUT for resource creation, I'd like to communicate that there are restrictions on the names that can be used to PUT.

So you can return a 405 or other error code to each PUT request, but is that enough for the client to deduce the server does not support PUT for creation at all - ie it will not accept that method anywhere? Perhaps it is...

They are different use cases, but both could make use of constrainedBy

[kjetilk]

On the first account, we use language like "When a server supports the HTTP PUT, POST and PATCH methods [...]", and in my interpretation, it always meant that you as the server admin is the final authority on the methods you want to support (and also, the URIs you accept, and so on). Thus, I think it is legitimate to take the simple solution, to not have PUT in the Allow header and respond to every PUT with a 405.

But indeed, it is limited what a client can generalize from this, it cannot infer that PUT isn't supported at all. I can only recall that OPTIONS * can be used this way, but I remember us having a lengthy debate about the semantics of the OPTIONS * method, and there were some problematic aspects to that, but I don't recall the details.

So, the Allow header is my answer for now. As for the second case, that seems like something that can be addressed in #44 .

[csarven]

Besides the error codes, there is nothing that would particularly suggest that PUT-to-create is not supported but PUT-to-modify is supported. Or extreme: only PUT-to-create-RDF-on-Mondays is supported... surely, there is no end to this. Server can only respond to the request with the error and perhaps provide a reason in the message body.

Alternatively, we need to come up with a matrix of constraints for HTTP request methods and response error codes or operations. So then the target of constrainedBy can be something like https://solidproject.org/TR/protocol#constraint-put-to-create .. but that's just a bit silly and too complicated to bother I think. Or have some other way that a server can list/describe all of its capabilities in a granular way - I believe there are issues generally touching this but not to the granularity as discussed here.

By the way, re constrainedBy matters, there is a PR for it #185 - sort of on hold for reasons..

Neither Allow: PUT or the Accept-Put header (defined in Protocol) helps to differentiate between creation (201) and modification (200, 204) for PUT.

---

Not sure if the use case is strong enough to bother with these requirements. Not the simplest problem to solve first.

[bblfish]

btw this came up on the solid test-suite channel on Tue, May 11 2021. The tests were using PUT to create resources and since my server does not support it, @michielbdejong was thinking of first checking the OPTIONS headers to see if the server supported that. But it looks like that won't work until we have constrainedBy clearly defined, or some other way for the server to let the client know that it supports the PUT-to-create behaviors.

[csarven]

With #185 , constraint discovery is now described in a non-normative section: https://solidproject.org/ED/protocol#constraints-problem-details . Essentially when a server wants to indicate its own specific constraints, i.e., beyond those defined by a spec, it can simply have a resource describing it.

Even with the availability of the constraint information, we don't yet have a data model that would help a client to know that a constraint is actually server-wide, as opposed to resource-specific, so that it no longer makes requests to create resources with a particular method. Ditto using structured error messages in RDF: #28

Essentially OPTIONS * with a specific ldp:constrainedBy may communicate what you are looking for but note that not all servers will support it - as per current spec - so clients can't rely on it.

This is advanced client behaviour and I'm not entirely sure how worthwhile it is - need more implementation experience. I love it but lets be pragmatic about what's sought for by implementers. My application for instance would try a method with a media type that the server accepts, and if that's not supported, it will try the next allowed method. I think that already does more than the average application. If you make your server advertise put-to-create constraint server-wide, I'll implement it on my end for fun and profit ;)

For now: respond with 405, omit PUT in Allow, omit Accept-Put, and if you're up to it, include Link header with ldp:constrainedBy targeting http://example.org/constraints#put-to-create

Closing this issue with the understanding that it can be revisited in the future if need be - perhaps towards documenting "matrix of constraints for HTTP request methods and response error codes or operations". For the time being, the suggestion for servers is to stick to resource-specific messaging, consider advertising their own specific constraints, and explore structured error messages.