CSS + UMA integration returns 500 instead of 404 for registered but non-existent resource in the Solid Server

[argahsuknesib]

When a resource URI is registered in UMA but does not exist as a real Solid container in the pod, unauthenticated GET requests return:

500 Internal Server Error

{"message":"Error while requesting UMA header: ."}

instead of a correct UMA challenge or a clear 4xx response.

Steps to reproduce:

1. Register a resource in UMA:
   http://localhost:3000/alice/derived/anomaly-alert/

2. Do NOT create the container in the Solid pod.

3. Perform:
   GET http://localhost:3000/alice/derived/anomaly-alert/

Observed:

• HTTP 500
• "Error while requesting UMA header"

4. Now create the container properly:
   PUT http://localhost:3000/alice/derived/anomaly-alert/
   (as LDP Container)

5. Repeat GET:
   GET http://localhost:3000/alice/derived/anomaly-alert/

Observed after creation:

• HTTP 401
• WWW-Authenticate: UMA ...

I would expect the behaviour to be one of the following in this case instead of an HTTP 500,

• 404 Not Found (resource does not exist)
• 401 Unauthorized with UMA challenge (if existence is acceptable but protected)
• or a clear error indicating resource not initialized

I assume the resource server attempts to construct a UMA challenge using metadata for a resource that is not resolvable as a valid Solid container, leading to an unhandled exception instead of a controlled response.

The impact this has is not breaking but still enough to be reported,

• Breaks benchmarking and runtime flows when resources are registered before creation
• Makes debugging difficult due to opaque failure mode

What do you think?

[termontwouter]

Thanks for raising this, @argahsuknesib !

Short answer: such scenarios should not be possible, so they should indeed not raise specific errors.

Longer answer:

The UMA specification (and by extension A4DS) does not target use cases where unexisting resources are registered -- even the semantics of that are not clear, i.e., registering something always implies that this something exists. The responsibility of keeping registrations in sync with actual resource state lies with the resource server, e.g., by always making sure a registration is created after and deleted before the corresponding resource. In theory, it would then not be possible to discover a resource via the UMA server that does not exist on the resource server.

Of course, it is possible that something goes wrong in certain situations, e.g., due to wrong assumptions, or long-lived tokens. In such cases, it is important that the resource server responds in a way that preserves privacy and security:

• If a request targets a URI that does not exist in the resource state, it is indeed 404 Not Found -- like you say -- regardless of the contents of the authorization token. In such cases, contact with the UMA server should not be required at all.
• If a request targets a URI that identifies a resource which exists in the resource state, but has no corresponding registration on the UMA server, the resource server should catch and hide the error response -- resulting from the verification of the authorization token -- and default to a 404 Not Found as well. After all, such a resource would have no policies defined over it, and any other response would disclose its existence to the client.