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

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?

Reproduce the GET behavior for the registered but uncreated resource at /alice/derived/anomaly-alert/, comparing it with the response after the LDP Container is created via PUT. Trace the UMA header handling that produces the 500 and define a controlled 404, 401 challenge, or other clear 4xx outcome; done means the uninitialized-resource case no longer returns the opaque 500.