Repository navigation
Handling URIs with a path component ending with the same segment term #107
Description
Can there be more than one URI with a path component ending with the same segment term? No.
Path segments separated by slash (/) entail hierarchical containment. Path segments:
- ending with a slash corresponds to a LDPC;
- not ending with a slash corresponds to a LDPR that's not a LDPC.
Examples:
/foo/ exists =>
/foocannot exist.
/foo/bar/baz exists =>
/foo/,/foo/bar/exists./foo,/foo/bar,/foo/bar/baz/,/foo/bar/baz/qux,.. cannot exist.
Normally 404 status code is used when there is no representation for a resource. When a segment term is used as part of the last path segment of a resource, should there instead be a redirect (301) to it when the same segment term is used for a resource without a representation? For example:
- If
/foo/exists, should request to/fooredirect to/foo/? - If
/fooexists, should request to/foo/redirect to/foo?
Activity
acoburn commentedon Nov 1, 2019
Is there a particular reason for this? Developer/implementation simplicity?
Is it therefore not possible to handle the alternative case, where, for example, a trailing slash is not present? That is,
/foo/barexists and/foois a container. (/foo/would redirect to/foo)csarven commentedon Nov 1, 2019
@acoburn Re "cannot exist" was in context of attempting to create
/foowhen/foo/already exists, and vice-versa.It is an open question as to what happens when one exists and an attempt is made to resolve (
GET) the other eg:AFAIK, some HTTP servers do the former but I haven't seen the latter. Should both redirect? Only one? Neither? Why?
acoburn commentedon Nov 1, 2019
Two points, both of which support the proposal outlined by @csarven above:
In the Trellis implementation, the answer is (currently) "no" to the first and "yes" to the second. But as part of implementing support for this proposal, I would be aiming for "yes" as the answer for each case.
TallTed commentedon Nov 1, 2019
Given that
404is to be returned when ACL does not permit access, I think the404should be returned before (i.e., instead of) the redirect in these cases, as doing otherwise exposes the existence information the404is meant to protect.csarven commentedon Nov 1, 2019
Allow me to further clarify what I've intended with the independent scenarios:
/foo/was created as a LDPC, then/foois requested./foowas created as a LDPR that's not an LDPC, then/foo/is requested.Re:
Right, that'd be fine for the first example
/foo/. It doesn't concern the second example.I find that interesting. How did that come about? I've seen 1. yes, 2. no (eg. Apache).
I like the consistency. 1. helps to add missing slash - moving foward, whereas 2. removes - moving backward.
csarven commentedon Nov 1, 2019
That's a good point.
(I arrived at
404basically because there is no matching resource.)mikeadams1 commentedon Nov 5, 2019
Not sure if this matters but, in the data browser both /foo/ and /foo exist. /foo gives you a view of the file but when you try to access it, it throws a 500, /foo/ allows access to the files if they are public.
kjetilk commentedon Nov 27, 2019
I have nothing much to add, as I think the discussion is good, I just want to poke the participants: Are we able to formulate a rough consensus here?
kjetilk commentedon Dec 18, 2019
@timbl mentioned in the F2F that he expected a
301onand indeed, there is a lot of precedent to support that. @TallTed's point is also a good catch, we should have that.
I have no strong opinions on the other case, but I note @acoburn 's statement that it is in Trellis.
Do we have a rough consensus that this is how we do it?
csarven commentedon Dec 19, 2019
Rough consensus capturing unique information:
Note: we agree on 404 for privacy reasons ie. not redirecting if not authorized, but I suggest that should be first addressed generally by resolving #14 . It is still useful to mention expected behaviour in the redirect case with that in mind.
kjetilk commentedon Dec 19, 2019
Nitpicking/devils advocacy:
Wouldn't that disallow
/foo/bazif/foo/bar/bazexist?(I mean, I get your point, and agree with it, it is just that people could actually write code to conform, and be surprised... :-) )
SHOULD...? I think that expectation is pretty strong... :-)
csarven commentedon Dec 19, 2019
Yes, just meant to capture the consensus but not exactly what goes into the spec.
This criteria is actually similar to or a variation on the SHOULD NOT re-use URI with a different identity for the resource in that it prohibits creating a URI with the same authority and path component differing only in the trailing slash. How about:
Server MUST NOT create a URI differing only in the trailing slash with that of an existing URI.
If for example /foo/bar/baz exists, then /foo/, /foo/bar/ exists. Attempting to create /foo/bar or /foo/bar/baz/qux (which attempts to create /foo/, /foo/bar/, /foo/bar/baz/) will fail because of existing /foo/bar/ and /foo/bar/baz.
Re redirect, no slash to slash is a common behaviour, but I'm not sure if slash to no slash is common. I figured MAY would keep it relaxed (and return 404), but I have no objection to using SHOULD for the redirect.
kjetilk commentedon Dec 19, 2019
👍 to the new formulation!
I think we can keep the SHOULD vs MAY open until the drafting phase. With that, I suppose we can move this to rough consensus?
6 remaining items
TallTed commentedon Dec 20, 2019
I should have said in my last here (which I've just edited to include this) -- "to
/index.htmlor/index.phpor/arbitrary.handleror whatever" because it's not just aboutindex.*.I don't think we are in agreement.
I don't think you're fully understanding my comments, and part of my relative quiet the past few days has been in an effort to let my concerns gel into a better presentation (which has not yet happened).
I may not be fully understanding your comments, either, try as I might.
I think there are several issues (including at least #109, #105, #119, #69, and #107, and maybe more) which are fairly inextricably and nearly indecipherably crosslinked. At the moment, I am not sure whether they can be more clearly separated, or would be better unified.
kjetilk commentedon Dec 20, 2019
This suggests to me that we should start drafting spec text, and work from there instead, it would make it more concrete, and may thus be a better discussion item. OK?
TallTed commentedon Dec 20, 2019
Perhaps.
First question in that direction is whether the idea is to describe current behavior of NSS (or Inrupt's successor) or other existing implementation, or to describe desired/intended behavior of future implementation (including updated versions of those existing implementations).
Second question is whether the Solid spec needs to restate everything from first principles -- or is (or can be, or should be) based on (and thus inherit) existing specs, particularly concerning HTTP and/or LDP server behaviors as defined in those specs.
My understanding was that Solid was based on both HTTP and LDP, but it's clear that this understanding is not entirely shared by others, so some of us seem to have been mistaken. It's also clear that current interpretation of those specs varies, and those variances need to be harmonized somehow.
kjetilk commentedon Dec 20, 2019
Right, I see the point, @TallTed. The spec work is not intended to be a departure from Solid as currently working, and NSS in many ways encode to understanding that was built around Solid in the years before the current crowd started working on. So, even though it can't be the source of sustained development because it is internally far from good enough, on the surface, it very nearly defines Solid, the main exception being in authentication, not in resource access.
I started out believing that Solid was essentially an application on the top of LDP, but through this fall we've had some discussions with Tim, and I have understood that while LDP is a starting point, the vision is much closer to a webization of the UNIX file system, but it borrows much from LDP, in particular the containment mechanism, which is used to model directories. That said, I still think that it is an important design goal to make Solid trivially implementable on the top of existing LDP servers. There are some balances to strike, but I think we're in a pretty good position.
csarven commentedon Dec 26, 2019
No one claimed it was strictly about
index.*. #109 literally exists because it acknowledges the general case for #69 . And in #107 (comment) I'm literally pointing at you to the comment that concludes (or at the very least proposes) that "index.*" need not be treated as a special case. I fail to understand what you disagree with other than the fact that you're telling me that you disagree meanwhile saying the exact same thing. I'll refrain from further judgement on that - perhaps we can better resolve this point in chat or spec call.This issue was generally intended to focus on resource URIs although generally excluded URLs. That was because there was some agreement on using the resource URI (as opposed to representation URL) when interacting with the primary resource. I'm happy to factor in representation URLs if we are indeed not excluding writing representation URLs. This is what you seem to be highlighting as the issue with the statement that we arrived through consensus. Are we closer to being on the same page?
kjetilk commentedon Dec 27, 2019
Is the problem that if you have a
/team/container, and a/team.ttlresource, then you would commonly, dereference the/team.ttlby using the URL/team, in which case we'd have a URI collision?I never thought about allowing
/team.ttlto be derefenced as anything but that, but I see that in the general case with conneg, that's what you do. So, do we need text to ensure that we avoid URI collisions in this case?elf-pavlik commentedon Dec 30, 2019
How does ResourceMapper work in NSS? would it allow to have both
/team/and/teamby mapping the later in underlying filesystem to something liketeam$.ttlorteam$.jsonld?csarven commentedon Jan 7, 2020
If /team/ exists:
There is no URI collision as I see it with that case but there may be other scenarios?