Some sites always redirect back to http://

[Kubuxu]

Example: fs:/ipns/glowing-bear.ipfs.ovh/

[lidel]

I assume we are talking about "native" fs: mode.
To clarify, does it happen only when local gateway is used?

---

Update @ 2017-02-21: see #87 (comment)

[Kubuxu]

Yes it does.

Also in this case using fs:/ breaks angular. I will open new issue about maybe meta tag for requesting for not being under fs:/.

[lidel]

Quick repro:

• open fs:/ipns/ipfs.io/ and hover over "Examples" link.
  Note that
  <a href="./docs/examples">Examples</a>
  points to fs:/ipns/ipfs.io/docs/examples
• click on it
• http://127.0.0.1:8080/ipns/ipfs.io/docs/examples/ is loaded

In short, there is a bug – directory paths must end with / :

• fs:/ipns/ipfs.io/docs/examples redirects to http:
• fs:/ipns/ipfs.io/docs/examples/ stays in fs:

Turns out the gateway normalizes root URIs. If it does not end with /, a redirect is returned:

Due to the way our current protocol handler works redirect sent by gateway breaks out from fs: namespace.

Sadly, we don't know if URL points to a directory or a file.
For example, fs:/ipns/ipfs.io/foo.bar can be a file (no redirect)
or a directory (redirect to fs:/ipns/ipfs.io/foo.bar/).

To solve this, we need to handle unexpected HTTP 302 from gateway somehow.

At first I thought maybe this old snippet by @the8472 will solve it, but the error was present in that code base too.

I did some diagnostics of channel.loadFlags in http-on-modify-request when channel.originalURI.scheme === 'fs'. I used ipfs.git.sexy because it does not fetch any additional artifacts.

Opening fs:/ipns/ipfs.git.sexy/ works as expected, and only one http-on-modify-request is logged:

console.info: newChannel routed to HTTP gateway:  http://127.0.0.1:8080/ipns/ipfs.git.sexy/
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy/, origUri: fs:/ipns/ipfs.git.sexy/
console.log: ipfs-firefox-addon: channel.loadFlags:  10011010010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  false

Opening fs:/ipns/ipfs.git.sexy yields two requests (second being the redirect target):

console.info: newChannel routed to HTTP gateway:  http://127.0.0.1:8080/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy, origUri: fs:/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon: channel.loadFlags:  10011010010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  false
console.log: ipfs-firefox-addon:  -----> uri:http://127.0.0.1:8080/ipns/ipfs.git.sexy/, origUri: fs:/ipns/ipfs.git.sexy
console.log: ipfs-firefox-addon: channel.loadFlags:  11011010000000000000000
console.log: ipfs-firefox-addon: LOAD_REPLACE   :  true

I tried to set the same loadFlags for the second request but it did not help -- flags were the same but final URL was http: (http-on-modify-request may be too late).

I'll look into this in spare time, but if anyone has any idea, feedback is appreciated.

[lidel]

There is an upstream ticket about this behavior at ipfs/in-web-browsers#8

[lidel]

Closing as it is no longer relevant.

Sadly "native fs: mode" is no longer possible due to missing WebExtension API.
Until such API is created, only basic handler will be present and it will always default to "http" in address bar.

See #164 for more details