Handling URIs with a path component ending with the same segment term

[csarven]

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 =>

• /foo cannot 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 /foo redirect to /foo/?
• If /foo exists, should request to /foo/ redirect to /foo ?

[acoburn]

/foo/ exists =>

/foo cannot exist.

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/bar exists and /foo is a container. (/foo/ would redirect to /foo)

[csarven]

@acoburn Re "cannot exist" was in context of attempting to create /foo when /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:

If /foo/ exists, should request to /foo redirect to /foo/?
If /foo exists, should request to /foo/ redirect to /foo ?

AFAIK, some HTTP servers do the former but I haven't seen the latter. Should both redirect? Only one? Neither? Why?

[acoburn]

Two points, both of which support the proposal outlined by @csarven above:

1. The "LDP best practices" document explicitly recommends having slashes at the end of container URIs
2. While this would involve a little bit of code on the Trellis side to make work (currently all resources with a final slash are redirected to a resource without a final slash in the URL), it won't be much work at all (I think).

It is an open question as to what happens when one exists and an attempt is made to resolve (GET) the other eg:

If /foo/ exists, should request to /foo redirect to /foo/?
If /foo exists, should request to /foo/ redirect to /foo ?

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]

If /foo/ exists, should request to /foo redirect to /foo/?
If /foo exists, should request to /foo/ redirect to /foo?

Given that 404 is to be returned when ACL does not permit access, I think the 404 should be returned before (i.e., instead of) the redirect in these cases, as doing otherwise exposes the existence information the 404 is meant to protect.

[csarven]

Allow me to further clarify what I've intended with the independent scenarios:

If /foo/ exists, should request to /foo redirect to /foo/?

/foo/ was created as a LDPC, then /foo is requested.

If /foo exists, should request to /foo/ redirect to /foo?

/foo was created as a LDPR that's not an LDPC, then /foo/ is requested.

Re:

The "LDP best practices" document explicitly recommends having slashes at the end of container URIs

Right, that'd be fine for the first example /foo/. It doesn't concern the second example.

In the Trellis implementation, the answer is (currently) "no" to the first and "yes" to the second.

I find that interesting. How did that come about? I've seen 1. yes, 2. no (eg. Apache).

But as part of implementing support for this proposal, I would be aiming for "yes" as the answer for each case.

I like the consistency. 1. helps to add missing slash - moving foward, whereas 2. removes - moving backward.

[csarven]

Given that 404 is to be returned when ACL does not permit access, I think the 404 should be returned before (i.e., instead of) the redirect in these cases, as doing otherwise exposes the existence information the 404 is meant to protect.

That's a good point.

(I arrived at 404 basically because there is no matching resource.)

[mikeadams1]

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]

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]

@timbl mentioned in the F2F that he expected a 301 on

If /foo/ exists, should request to /foo redirect to /foo/?

and 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]

Rough consensus capturing unique information:

• Server MUST NOT have a URI with a path component ending with a segment term that is already in use by another URI.
• Server MAY redirect a request with 301 from a non-existing URI to an existing URI with a matching path component ending with the same segment term. Behaviour pertaining to authorization MUST proceed this optional redirect.

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]

Nitpicking/devils advocacy:

Server MUST NOT have a URI with a path component ending with a segment term that is already in use by another URI.

Wouldn't that disallow /foo/baz if /foo/bar/baz exist?

(I mean, I get your point, and agree with it, it is just that people could actually write code to conform, and be surprised... :-) )

Server MAY redirect a request with 301 from a non-existing URI to an existing URI with a matching path component ending with the same segment term.

SHOULD...? I think that expectation is pretty strong... :-)

[csarven]

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]

👍 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?