-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ldp:constrainedBy recommendations #44
Comments
Generally agree on making use of Before discussing a vocabulary for error details - generally a good idea any way, and I think we have some options there - can we inspect the underlying mechanism and iron out some assumptions:
|
Related #28 |
Also agree that there's a home for it here 👍
I think this depends on the type of constraint - it cannot be generalized. For example - a wac acl is a constraint, but it is only advertised if the acl:agent has acl:Control privileges. Regardless, if the goal is to stick with LDP conventions, the statement in 4.2.1.6 of the LDP spec only requires as a MUST that LDP servers must publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with an appropriate context URI, a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints [RFC5988], to all responses to requests that fail due to violation of those constraints IMHO - we should stick to the case LDP requires, which is including a Link header with a context URI, a link relation of
Another case where I think it depends on the type of constraint, and so it should be determined in the definition for that type (in resource metadata). |
Here's why I don't think we should use ldp:constrainedBy as the link relation used to advertise constraints of all types in Link headers (realized I didn't address this head on):
|
re WAC/ACL, why? Minimise/eliminate attack vector? If so, what kind of attacks are unique to ACL resources? Related: I take it that no URI pattern will be specified for ACL resources in any case.
Fine by me if those, similar or relevant questions are addressed in the definitions.
Generally agree. IIRC, we haven't however agreed to specify the model for error descriptions that can be used in the RDF body of the target of the constrainedBy URI . Issues like #146 , #112 , #111 , #28 can help here. Whether all potential errors should be specified or left at the discretion of the server (provided that they follow an outline, be machine-readable etc) also needs to be decided.
As I understand it, constrainedBy would explain the conditions that needs to be met. An ACL resource doesn't actually articulate that - and certainly not useful if the proposal to only expose rel=acl if user has Control - but I can see how it can be purposed that way. I do however see that shapes or machine-readable specs (or fragments within) to be closer for intended use. |
Servers MUST publish any constraints on clients’ ability to create or update resources by adding a |
Proposal for the constraint URIs: The target URI of the constrainedBy can be a URI that is part of the Solid spec defining the constraint. The test suite uses those constraints in which the implementation reports are also based on. The issue on having an HTML+RDFa spec: #6 can in fact help to address with constrainedBy recommendation in a human- and machine-readable way. For example, the LDN spec has URIs for each constraint and described with RDFa. The URIs are used in the test suite and implementation reports (eg. https://www.w3.org/TR/ldn/#test-receiver-post-response-contraints-unmet defines the server requirement on failing a request.) So, there is at least a way to refer to Solid spec defined constraints. If there are other constraints or server wishes to extend the description of the constraint in their own environment, they can do so at a URI under its control. For example, the constraint can be in a language (different than the Solid spec) that the server supports and based on content negotiation with the client. If linking to the Solid spec poses a security risk - because it is under a different authority - we can suggest a best practice for servers where they can reuse the definitions from the spec, extend if need to, and use their own URIs. |
As support for the proposal above, the Web Annotation Protocol https://www.w3.org/TR/annotation-protocol/ in fact has the same criteria. The WAP spec is not in RDF to the degree that it suggests:
however, the intention is the same. In Solid spec's case, this is actually feasible (as demonstrated by LDN). Note also that WAP recommends:
which is what I've suggested earlier - with some exceptions on the kind of resources of course. |
I would like to be able to express that my server only allows creation of containers with PUT if the URL does not contain any dots. Ie it can create |
With the exception of dot-segments, I think it'd be up to servers to whether a dot in a path segment is allowed. If server doesn't allow client to allocate a URI containing a dot in a path segment, it should probably respond with a 403. Unless the spec has something to say about the dots in path segment, in which case the URI reference can be the requirement in the spec, I don't think ldp:constrainedBy is necessary. Message in body might suffice. Aside: |
It is an implementation detail on the server. But for the protocol, we need the server to be able to communicate such details to the client. We need a way to let clients know what type of names they can reliably use to PUT to a server, or else the only real option is POST. (Or is a client meant to try to guess the acceptable names?) |
To clarify, what you want to express is a unique implementation behaviour. Servers can describe their specific constraints using ldp:constrainedBy with their own identifiers and descriptions. Alternatively (but this is not what you want), indicate the contraints in the response body - #28 goes in the direction of structured error responses. |
#185 resolves this issue. |
The LDP specification introduces an IRI to be used to advertise any constraints on the ability of a client to create or update resources:
Link: <https://example.com/SpecificErrorCondition>; rel="http://www.w3.org/ns/ldp#constrainedBy"
If Solid published a common vocabulary of error conditions, this feature could potentially be used to accomplish a high level of interoperability across servers. Is such a recommendation within the scope of the Solid specification?
The text was updated successfully, but these errors were encountered: