All the comments about requiring a spec issue of the 404 tests depend on what the spec says in general about that case, since that is what I couldn't find.

Support for OPTIONS request has been added so they now also work in the table.

That said, I think I might have a solution for the three remaining different rows (two of which are stricter and hence already acceptable): can we—in a new PR—introduce an Existence mode that the modesExtractor returns, and if not covered by the target itself, will require the WebACL permissionReader to check with the parent?

I feel like this goes against how the modes work/are interpreted. All other modes are binary permissions that you either have or don't, depending on what the reader returns. An Existence mode that has to be interpreted differently goes against that.

It depends a bit on if this is a WebACL thing, or a general Solid permissions thing. If only WebACL requires read permissons on a parent container to influence the response code, we should add an existence check in that reader. If this is a general Solid thing, the modesExtractor should output a key/value object with the keys being identifiers and the values being the modes required on those resources, as originally discussed in the related issue.

I feel like this goes against how the modes work/are interpreted. All other modes are binary permissions that you either have or don't, depending on what the reader returns. An Existence mode that has to be interpreted differently goes against that.

I don't think so. The modes extractor will say "agents need to be able to Read and Write to the resource to perform the operation". So my proposal is to make it say "agents need to be able to ExistenceCheck and Read and Write to perform the operation". That is binary too?

It depends a bit on if this is a WebACL thing, or a general Solid permissions thing.

Exactly; what I wrote above would also work for another permissions thing that differently arranges "need to be allowed to know that X exists".

If only WebACL requires read permissons on a parent container to influence the response code, we should add an existence check in that reader.

Yes; so that's why we'd send the Existence bit over in modes as a required check in some cases. And then the reader would now: ah, for ACL, existence check means looking at the parent in these cases.

If this is a general Solid thing, the modesExtractor should output a key/value object with the keys being identifiers and the values being the modes required on those resources, as originally discussed in the related issue.

I don't think so; I only want to encode "agent needs to be allowed to find out if the target resource exists" as a bit. The fact that in WebACL, this is checked on the parent, should only be in the WebACL-specific reader.

I don't think so; I only want to encode "agent needs to be allowed to find out if the target resource exists" as a bit. The fact that in WebACL, this is checked on the parent, should only be in the WebACL-specific reader.

We are not checking the parent container because of WebACL reasons though. We are checking the parent container because the ldp:contains triples of a parent container exposes information about its child resources and vice versa. A DELETE on a non-existing resource needs to return 401 if you don't have read permissions on the parent container, because otherwise this would expose that the container does not have a corresponding ldp:contains triple. Specifically mentioned in the comment above as "Disclosing whether a resource exists requires Read access on its container.". So that follows from the Solid definitions, not the WebACL ones.

Returning an Existence mode is essentially the same as encoding the information "Does the agent have Read permissions on the parent container", independent of the authorization scheme being used.