revise link acl test

[bourgeoa]

revise link acl test and add mkdir in run-against...

[bourgeoa]

I agree but failed to find an easy way to do that :

• headers.get('link') returns something like : <test.txt.acl>; rel="acl", <test.txt.meta>; rel="describedBy", <http://www.w3.org/ns/ldp#Resource>; rel="type"
• the result need to be parsed
• and the acl Url can be relative to the resource, relative to the pod or absolute depending on the server.

I supposed the test was not to check that Alice and Bob gave the same acl url.

[edwardsph]

I forgot it wasn't parsed at that point. So you could use something like this to parse out the acl URL:

    private getAclLinkFromHeader(headers): string {
        if (!headers || !('link' in headers)) return null;
        const aclLink = headers['link'].split(', ').find((link) => link.includes('; rel="acl"'));
        if (!aclLink) return null;
        return aclLink.split(/[<>]/)[1];
    }

and then to resolve the URL: new URL(aclLink, resourceUrl). I agree, it depends on the purpose of the test but I thought I would suggest this in case it was useful elsewhere.

[bourgeoa]

and then to resolve the URL: new URL(aclLink, resourceUrl)

This will only work if aclLink is relative to resource (ex: text.acl) but not if it is relative to pod root (ex.: ./pathToAcl/resourceUrl.path.acl) or absolute url which are all valid depending on how server stores acl's (to my understanding).

[edwardsph]

I would be very concerned if resolving the URL like that didn't work. Surely the client should not need to know how the server stores ACLs to be able to access one. The link and the resource URL must be sufficient. I believe there are 4 theoretical options for the ACL link on a resource at http://server/folder/test.ttl:

• test.ttl.acl - resolving against the resource URL gives a sibling resource http://server/folder/test.ttl.acl
• subfolder/test.ttl.acl - resolving against the resource URL will add this onto the path and you end up with http://server/folder/subfolder/test.ttl.acl
• /somewhere/test.ttl.acl - resolving against the resource URL will drop its path and you end up with http://server/somewhere/test.ttl.acl and it may not be a sibling of the resource
• http://server/elsewhere/test.ttl.acl - the resolve does nothing since the URL is already absolute

See the examples at https://developer.mozilla.org/en-US/docs/Web/API/URL/URL

[bourgeoa]

I miss-read the node URL

[edwardsph]

LGTM