Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

Make handling of default resource for container explicit #134

Open
megoth opened this issue Jan 24, 2019 · 13 comments
Open

Make handling of default resource for container explicit #134

megoth opened this issue Jan 24, 2019 · 13 comments

Comments

@megoth
Copy link

megoth commented Jan 24, 2019

If I have understood the handling of node-solid-server the precedence for default resource for containers is: index.html > index.ttl > "virtual resource for container, listing the content of that containers as triples". (The latter might tie into nodeSolidServer/node-solid-server#1040, but that's another discussion.)

I just want to verify that this is what we want, and if so, make it explicit in the spec, to make sure all servers handle this the same.

@melvincarvalho
Copy link
Member

That's what I thought it was. But might be worth confirming with Tim.

Id suggest this was a server specific item, that could first of all go into the node solid server API description as is required by semver (but we've been a bit lax about to date).

Then we could consider putting it upstream in the solid spec. First observation is that this seems a little like .htaccess rules in things like apache, which tend to show a bit of flexibility.

@csarven
Copy link
Member

csarven commented Jan 24, 2019

@megoth I'm missing some details. Are you referring to q values? Or if index.html is physically on the disk, use it, if not, look for index.ttl, and so on? Literally classic index view?

@megoth
Copy link
Author

megoth commented Jan 24, 2019

@megoth I'm missing some details. Are you referring to q values? Or if index.html is physically on the disk, use it, if not, look for index.ttl, and so on? Literally classic index view?

I was thinking of the latter.

@csarven
Copy link
Member

csarven commented Jan 24, 2019

I don't think this is (or should be) in scope of a "spec". It feels very implementation specific to me. My suggestion is to document it for node-solid-server only.

@megoth
Copy link
Author

megoth commented Jan 24, 2019

Ok, we could leave it out of the spec.

The reason I initially raised this issue was because of solid/web-access-control-spec#36, where I ask to make it explicit that when a server responds a default resource (whatever that may be) when dereferencing a container, and that resource is actually a file (like index.html, or index.ttl), we also need to check for that file's ACL-settings.

@csarven
Copy link
Member

csarven commented Jan 24, 2019

ACL for the "files" on disk or the HTTP "resource"?

Are we cool to close this issue?

@megoth
Copy link
Author

megoth commented Jan 24, 2019

ACL for the "files" on disk or the HTTP "resource"?

Are we cool to close this issue?

Well, I guess it depends on how the server implements it; if it's a classic index view, and the server sends the content of index.html as a response to a container, we should also check that file's ACL-settings. But shouldn't be part of the spec, I guess. (I'm a bit unfamiliar with what should and shouldn't be in a spec, so you'll have to excuse my ignorance.)

That would answer solid/web-access-control-spec#36 too, I think, so I'll close both of these issues.

@megoth megoth closed this as completed Jan 24, 2019
@kjetilk
Copy link
Member

kjetilk commented Jan 24, 2019

It is pretty implementation specific but, I think it is an issue that more implementers will encounter. The issue is really this:

The client asks for e.g. /foo/ and the server may decide to serve /foo/index.html or some other resource through some mechanism (e.g. Accept headers, q-values, etc) that is not the concern of this issue. The server has both /foo/.acl and /foo/index.html.acl. Which ACL file does it apply? I would ignore the latter, and I think that is what NSS 5 does right now, but I can imagine people finding that surprising...

So, I'm not quite sure it shouldn't be specked.

@megoth
Copy link
Author

megoth commented Jan 25, 2019

Seems we should ask @timbl about it at least, to get his input. I'll reopen this until we have his feedback.

@megoth megoth reopened this Jan 25, 2019
@RubenVerborgh
Copy link
Contributor

I do not think the solid spec should govern what is on disk; there might even be no disk or no filesystem.

However, we what we should be concerned about is that, if representations of a resource have their own URL, that they are protected by the same ACLs. Access control should protected resources, not representations.

For example, /foo/ is the main resource, with /foo/index.html or /foo/index.ttl are representations; ACL should be set on /foo/, but also cover representations. However, in this spec, no assumptions regarding representation URLs should be made.

@kjetilk
Copy link
Member

kjetilk commented Jan 25, 2019

For example, /foo/ is the main resource, with /foo/index.html or /foo/index.ttl are representations; ACL should be set on /foo/, but also cover representations. However, in this spec, no assumptions regarding representation URLs should be made.

Indeed. So, what isn't clear to me is if the current implementation makes the opposite assumption, or if it something wrong with the ACL currently applied on dev.inrupt.net or if it is a bug in the beta.

@RubenVerborgh
Copy link
Contributor

The current ACL does not make any assumptions on this; building this in with the current NSS will be very challenging.

@csarven
Copy link
Member

csarven commented Nov 5, 2019

if representations of a resource have their own URL

Edit: IIRC, NSS doesn't advertise the representation through the resource. Accessible independently however re HTTPFilenameMapping.

@acoburn , what does Trellis do?

Any Solid-based/like server implementations using Content-Location for representation metadata? Any redirecting? Do their updates go through the resource or can representations be individually updated?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants