Add gateway route /ipfs/*

[harshjv]

Add gateway route /ipfs/*

• Stream content with proper content-type when file name is available
• Allow directory listing with the same style as https://ipfs.io/ipfs/<some-dir-hash>

Preview

Related issue

#693

[kumavis]

Looks good. Did not actually run or test it. There's some minor things.

1. non-standard white-spacing ( aligning against token on previous line instead of just depth * indentSize )
2. introduces some TODO's in comments -- better to leave them out, note whatever shortcomming, and create an issue for it.

I guess I'd also expect go-ipfs and js-ipfs to just serve the same app, so it can be iterated on as a separate project

[kumavis]

test fails bc of some gulp-coverage breakage

[harshjv]

@kumavis Fixed indentation and removed TODO comment

[kumavis]

Dont mind the security warning, its a known situation and is in an outdated copy of the build tool

[kumavis]

I guess I'd also expect go-ipfs and js-ipfs to just serve the same app, so it can be iterated on as a separate project

@diasdavid thoughts?

otherwise LGTM

[daviddias]

I won't have the time to review this soon. Nevertheless one thing that caught my eye is that there aren't any tests. Also, if we are going to push forward and add the gateway to js-ipfs, I would prefer to:

• rename the folder http-api to just http
• create two folders, one being api and the other being gateway
• move https://github.com/ipfs/js-ipfs/blob/master/src/http-api/index.js out to the http folder, so that it spawns the daemon and loads both api and gateway.

[dignifiedquire]

One other note, the current code base does not use promises, and we would like to keep it that way for now.

[kumavis]

One other note, the current code base does not use promises, and we would like to keep it that way for now.

I think this is another point for breaking the ui out into its own project

[daviddias]

Yeah, there is the webui and this 'file viewer' thing. Both can be their own projects I believe, transforming the file viewer to a NWA instead of a server side rendered thing, so that it can be used easily by go and js-ipfs.

[victorb]

@diasdavid bit unclear what the decision is for this PR. Should we focus on merging this or should we focus on splitting it out and integrate as external module?

[daviddias]

@victorbjelkholm

[harshjv]

@diasdavid Something like this? https://github.com/harshjv/ipfb
NPM: https://www.npmjs.com/package/ipfb

[daviddias]

@harshjv completed missed the last comment. https://github.com/harshjv/ipfb looks great, that file browser should be something that both go and js can use and not only js.

Could you handle these tasks first:

• Add gateway route /ipfs/* #698 (comment)
• Add gateway route /ipfs/* #698 (comment)
• Tests.

I would be comfortable merging this if these tasks were completed. We can figure out how to have 'one file-browser' for both implementations next. It is very probable that by having the Gateway working on js-ipfs, that we will develop an even better file browser since it will enable more JavaScripters to play with it :)

Btw, js-ipfs now fully supports paths as in /ipfs/hash/a/b/c.txt

[ya7ya]

@diasdavid @harshjv Hi there, Are there any plans to fix the minor conflict and merge this PR ??

[daviddias]

@ya7ya see above, there are more things to do than merge conflicts. Wanna help?

[ya7ya]

@diasdavid Yeah, I'm currently swamped with work trying to figure out the problem with #946 which is desperately needed for a project i'm working on, but I can try to help by finishing the tasks mentioned in your previous comment

[ya7ya]

hey @diasdavid , I been working on the points you mentioned above to get this thing done, But there is an issue I thought you might be able to clarify.

The go-ipfs implementation throws an error when you cat a directory, which is useful to figure out whether a path should be served or render the ui for the index. in js-ipfs this error is never triggered so figuring out the directory isn't straightforward.

Does js-ipfs cat implmentation has that ErrIsDir Error ?? or do I need to figure out another way to find that out ?

[daviddias]

Merging this PR into a new target branch feat/gateway so that @ya7ya and @harshjv can collaborate together on it (without having to PR the PRs)