-
Notifications
You must be signed in to change notification settings - Fork 103
Make handling of default resource for container explicit #134
Comments
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. |
@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. |
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. |
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. |
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. |
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. So, I'm not quite sure it shouldn't be specked. |
Seems we should ask @timbl about it at least, to get his input. I'll reopen this until we have his feedback. |
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, |
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. |
The current ACL does not make any assumptions on this; building this in with the current NSS will be very challenging. |
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 |
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.
The text was updated successfully, but these errors were encountered: