non existent .meta are displayable

[bourgeoa]

for exemple /public/.meta do not exist but return 200 OK and has a content
I was expecting 404

# curl -I https://bourgeoa.solidcommunity.net:3000/public/.meta
HTTP/1.1 200 OK
Vary: Accept,Authorization,Origin
X-Powered-By: Community Solid Server
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Accept-Patch,Accept-Post,Accept-Put,Allow,Content-Range,ETag,Last-Modified,Link,Location,Updates-Via,WAC-Allow,Www-Authenticate
WAC-Allow: user="read",public="read"
Content-Type: text/turtle
Date: Mon, 26 Feb 2024 16:20:18 GMT
Connection: keep-alive
Keep-Alive: timeout=5

# curl -HI https://bourgeoa.solidcommunity.net:3000/public/.meta
@prefix dc: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix posix: <http://www.w3.org/ns/posix/stat#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<https://bourgeoa.solidcommunity.net:3000/public/> a ldp:Container, ldp:BasicContainer, ldp:Resource;
    dc:modified "2024-02-26T16:13:34.000Z"^^xsd:dateTime;
    posix:mtime 1708964014;
    ldp:contains <https://bourgeoa.solidcommunity.net:3000/public/chat%3A3000/>, <https://bourgeoa.solidcommunity.net:3000/public/text.ttl>, <https://bourgeoa.solidcommunity.net:3000/public/test.jsonld>, <https://bourgeoa.solidcommunity.net:3000/public/privatemedia/>, <https://bourgeoa.solidcommunity.net:3000/public/signed-chat/>, <https://bourgeoa.solidcommunity.net:3000/public/activitypods.org/>, <https://bourgeoa.solidcommunity.net:3000/public/Text.md>, <https://bourgeoa.solidcommunity.net:3000/public/test-chat/>, <https://bourgeoa.solidcommunity.net:3000/public/webhooks.jsonld>, <https://bourgeoa.solidcommunity.net:3000/public/mypod.store/>.

If I create the /public/.meta with some content, this content is added to the previous displayed content.
.meta seems to be a default for some server containment statements.

My understanding of the spec was that for container .meta content is added to the container containment statements and was user managed (here that is the case but not fully user managed.)

For /public/text.ttl.meta we have the same result 200 OK
If I add some user content, this user content is not added to /public containment statements (only the server managed ones)

# curl -HI https://bourgeoa.solidcommunity.net:3000/public/text.ttl.meta
<https://bourgeoa.solidcommunity.net:3000/public/text.ttl> a "test example", <http://www.w3.org/ns/ldp#Resource>;
    <http://purl.org/dc/terms/modified> "2023-11-24T16:55:38.000Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>;
    <http://www.w3.org/ns/ma-ont#format> "text/turtle";
    <http://www.w3.org/ns/posix/stat#mtime> 1700844938;
    <http://www.w3.org/ns/posix/stat#size> 13.
<http://purl.org/dc/terms/> <http://purl.org/vocab/vann/preferredNamespacePrefix> "dc".
<http://www.w3.org/ns/ldp#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "ldp".
<http://www.w3.org/ns/posix/stat#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "posix".
<http://www.w3.org/2001/XMLSchema#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "xsd".

[joachimvh]

The spec doesn't actually say that much about metadata which is why we made some choices when implementing this with the plan to change if more specific requirements are established. Specifically what the contents of a container should be on a GET request. A related discussion was had here: CommunitySolidServer/CommunitySolidServer#1461

Currently CSS automatically generates the required triples for a container, such as ldp:contains and the other required triples. Besides that it also adds any triples that were added by the user to the corresponding metadata file.

For non-container resources the metadata is only visible by accessing the metadata resource itself as we can't add that to the data itself. We also do not add that metadata to the encapsulating container, as that might leak information. If someone has read access to /foo/ but not to /foo/bar, they should not be able to read the metadata of /foo/bar by doing a GET request to /foo/.

The metadata you see when doing a GET to, for example /foo/.meta, is a combination of server-managed and user-managed metadata. As there will always be server-managed metadata, this will never return a 404 (as long as the original resource exists). So it is possible to get a 200 there even though there might not be a corresponding file on disk.

[bourgeoa]

Thanks for your response. This is quite a change to what I expected and from NSS implementation.

Another question I tried to update https://bourgeoa.solidcommunity.net:3000/public/text.ttl.meta with SolidOS
And got an error 405 on PUT
I went to look at the authorized method on GET response and there are none.
The discussion CommunitySolidServer/CommunitySolidServer#1461 explains that only PATCH is allowed

# curl -i https://bourgeoa.solidcommunity.net:3000/public/text.ttl.meta
HTTP/1.1 200 OK
Vary: Accept,Authorization,Origin
X-Powered-By: Community Solid Server
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Accept-Patch,Accept-Post,Accept-Put,Allow,Content-Range,ETag,Last-Modified,Link,Location,Updates-Via,WAC-Allow,Www-Authenticate
WAC-Allow: user="read",public="read"
Content-Type: text/turtle
Date: Tue, 27 Feb 2024 10:09:21 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

<https://bourgeoa.solidcommunity.net:3000/public/text.ttl> a "test example", <http://www.w3.org/ns/ldp#Resource>;
    <http://purl.org/dc/terms/modified> "2023-11-24T16:55:38.000Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>;
    <http://www.w3.org/ns/ma-ont#format> "text/turtle";
    <http://www.w3.org/ns/posix/stat#mtime> 1700844938;
    <http://www.w3.org/ns/posix/stat#size> 13.
<http://purl.org/dc/terms/> <http://purl.org/vocab/vann/preferredNamespacePrefix> "dc".
<http://www.w3.org/ns/ldp#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "ldp".
<http://www.w3.org/ns/posix/stat#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "posix".
<http://www.w3.org/2001/XMLSchema#> <http://purl.org/vocab/vann/preferredNamespacePrefix> "xsd".

[joachimvh]

The 405 response itself will have an Allow header and an Accept-Patch header. I see it also has an Accept-Post header so there are some things that should not be there as well apparently.

There is also some documentation on how CSS handles metadata: https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/metadata/