Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some sites always redirect back to http:// #87

Closed
Kubuxu opened this issue Feb 22, 2016 · 5 comments
Closed

Some sites always redirect back to http:// #87

Kubuxu opened this issue Feb 22, 2016 · 5 comments
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) status/blocked/missing-api Blocked by missing API

Comments

@Kubuxu
Copy link
Member

Kubuxu commented Feb 22, 2016

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

@lidel
Copy link
Member

lidel commented Feb 22, 2016

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
Copy link
Member Author

Kubuxu commented Feb 22, 2016

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 lidel added the kind/bug A bug in existing code (including security flaws) label Feb 24, 2016
@lidel lidel self-assigned this Mar 5, 2016
@lidel
Copy link
Member

lidel commented Mar 5, 2016

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:

2016-03-05-160352_565x195_scrot

2016-03-05-160408_565x195_scrot

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 lidel added the help wanted Seeking public contribution on this issue label Mar 5, 2016
@lidel lidel removed their assignment Mar 5, 2016
@lidel lidel added the status/blocked/missing-api Blocked by missing API label Aug 6, 2016
@lidel
Copy link
Member

lidel commented Feb 20, 2017

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

@lidel
Copy link
Member

lidel commented Mar 19, 2017

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

@lidel lidel closed this as completed Mar 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) status/blocked/missing-api Blocked by missing API
Projects
None yet
Development

No branches or pull requests

2 participants