Environment

• Server version: 7.1.7
• Node.js version: v25.2.1
• npm version: 11.6.2

Description

Metadata resources (.meta files) do not return an Accept-Patch header when requested, making it impossible for clients to discover that these resources support PATCH operations.

Expected Behavior

When making a GET or HEAD request to a metadata resource (e.g., http://localhost:3000/resource.txt.meta), the server should return headers indicating which methods are supported and which content types are accepted for PATCH operations:

GET /resource.txt.meta HTTP/1.1
Host: localhost:3000

HTTP/1.1 200 OK
Allow: GET, HEAD, PATCH, OPTIONS
Accept-Patch: text/n3, application/sparql-update
Content-Type: text/turtle
...

This is critical for client discovery of server capabilities, as specified in the Solid Protocol and HTTP standards.

Actual Behavior

Currently, when requesting a metadata resource, the Accept-Patch header is missing from the response:

GET /resource.txt.meta HTTP/1.1
Host: localhost:3000

HTTP/1.1 200 OK
Content-Type: text/turtle
...
(no Accept-Patch header)
(no Allow header)

Steps to Reproduce

1. Start the Community Solid Server with default configuration
2. Create a resource:

   curl -X PUT http://localhost:3000/test.txt \
     -H "Content-Type: text/plain" \
     -d "test content"

3. Request the metadata resource with verbose headers:

   curl -i http://localhost:3000/test.txt.meta

4. Observe that the response does not include an Accept-Patch header

Impact

• Clients cannot discover that metadata resources support PATCH operations
• Clients cannot discover which patch formats are supported (N3 Patch vs SPARQL Update)

Additional Context

• Regular resources (non-metadata) correctly return the Accept-Patch header
• PATCH operations on .meta resources DO work correctly when attempted (using text/n3 or application/sparql-update content types)
• Only the header advertisement is missing; the functionality itself works