fix: don't expect ipfs to preserve a leading slash

[Stebalien]

Go-ipfs now normalizes paths before adding files. This will:

• remove any leading slashes.
• remove any /./ components.
• normalize any /../ components.

That breaks this test which assumes that paths are returned exactly as specified.

[alanshaw]

I'm glad these are now normalized, we'll have to submit a PR to JS IPFS to implement this. It needs some tests to ensure the normalisation happens.

Separately, I think this change breaks the path given to resolve later in the test: /ipfs/${rootHash}${path}, I think we'd end up with /ipfs/QmHashpath/to/testfile.txt.

[alanshaw]

@Stebalien would you mind pointing me in the direction of the PR(s) that implemented this? I just want to make sure we do the same thing...For instance, I'd like to know what happens with paths that try to traverse above root e.g. '../foo' => 'foo' or '../foo' => error? Also windows style paths i.e. backslashes and C:\\.

[alanshaw]

See ipfs/go-ipfs-files#6 and https://golang.org/pkg/path/filepath/#Clean

(Note: we might want to consider rejecting .. instead of normalizing)

[Stebalien]

Separately, I think this change breaks the path given to resolve later in the test: /ipfs/${rootHash}${path}, I think we'd end up with /ipfs/QmHashpath/to/testfile.txt.

(got to get better about actually running tests)

---

This changed (incidentally) in ipfs/go-ipfs-files#6. Normalized with https://golang.org/pkg/path/#Clean.

Actually, I think we're going to need to think through this a bit. Clean normalizes .. while we should probably reject it. Thoughts?

(edited: I found the wrong Clean function)

[Stebalien]

(got to get better about actually running tests)

Ah, that's why I didn't. Didn't want to learn how to replace npm deps.

[alanshaw]

Actually, I think we're going to need to think through this a bit. Clean normalizes .. while we should probably reject it. Thoughts?

Do you mean .. when attempting to navigate up from root or .. anywhere in the path?

For the former, I don't have strong feelings on it. It's pretty common to not error when attempting to navigate up from root, go-lang Clean being the case in point. But also hyperlinks on the internet, path.resolve in Node.js and cd / && cd ../ && pwd works. That said, a traversal up from root is either user error or malicious so I'd be ok to error in this situation. On balance I think I'm slightly more inclined to resolve /.. to / without error.

For the latter, I guess it's just convenient to allow this when adding and it's easy to do the resolve. People will just expect it to work so why get in the way?

I noticed that Clean doesn't specify anything about \...do you think we should replace \ with / and trim /[a-zA-Z]:\\/ from the start?

[Stebalien]

Do you mean .. when attempting to navigate up from root or .. anywhere in the path?

Both? The request body feels like a declarative filesystem layout. For example, I I'd expect tar to reject tar files with .. in paths.

But I don't really fell all that strongly about this.