Response types for forbidden resources

[acoburn]

For background, please see solid/specification#14

From section 6.5.3 of RFC 7231

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

Trellis currently conforms to this. The HTTP specification goes on to state:

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

It would be nice to make this response type configurable in Trellis. That is, by default, a 403 Forbidden response will be generated for this condition, but a server administrator could configure the server to "hide" these resources by having it respond instead with a 404 Not Found.

[ajs6f]

I'm not going to lie down in the road over this, but I must disagree. This seems like a perfect example of something that should be done at an outer layer of architecture (e.g. in the caching layer or via some other proxy). Converting 403->404 inside the repository means that clients for indexing or journaling will not know whether to authenticate or to assume a missing resource. Logs for proxy layers will contain less information. "Downsampling" information internally seems premature.

This seems to me like a perfect candidate for Trellis judo: doing the work not by adding code (to maintain forever) but by documenting a sound pattern that can be implemented in your choice of technology (httpd, Camel, etc.).

[acoburn]

That is an excellent argument. There are multiple ways one could handle a mapping of 403 -> 404 codes in various points of external layers. Putting this inside the AuthZ code adds complexity -- complexity that could be clearly handled elsewhere.

[ajs6f]

If it's worth doing, it's worth not doing.

Something about that doesn't sound quite right, but I'm sure it all works out.