[go: nahoru, domu]

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

localhost subdomains do not work on Safari (macOS) #206

Open
Gozala opened this issue Jul 8, 2020 · 21 comments
Open

localhost subdomains do not work on Safari (macOS) #206

Gozala opened this issue Jul 8, 2020 · 21 comments
Labels
kind/bug A bug in existing code (including security flaws) status/blocked Unable to be worked further until needs are met

Comments

@Gozala
Copy link
Gozala commented Jul 8, 2020

Version information:

go-ipfs version: 0.6.0
Repo version: 10
System version: amd64/darwin
Golang version: go1.14.4

Description:

After 0.6.0 version local gateway started redirecting to localhost subdomains (guessing ipfs/kubo#651) e.g. going to following address http://localhost:8080/ipfs/QmTQ1PTYhZNt9q7bJ1r6R18ctj6NoHTzvqdLgiq2UzRZHU/ redirects to http://bafybeicle2hoymo7rsqf7w5mjyssntevvwpylixlri63azrppm6lzv7vvm.ipfs.localhost:8080/ which fails in Firefox

image

And in Safari

image

Although it does work in Chrome.

As per @lidel

..this is known problem on some platforms with combo of strict DNS resolver and browser vendors who don't implement "let localhost be localhost" 6.3.3 @ https://tools.ietf.org/html/rfc6761#section-6.3
(upstream bug for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1220810)
Until that is resolved, the localhost subdomain fix is to use go-ipfs' Gateway port as HTTP proxy for loading *.localhost websites – that way we avoid using OS DNS resolver that fails to resolve *.localhost hostnames
(If you have IPFS Companion installed in Firefox, it will set up proper proxy automatically) (edited)
Follow updates in #109 (comment)

Despite proxy solution, I think this is a major regression. People installing IPFS for the first time will not know this and even knowing this they may not want to use IPFS as proxy (maybe they don't want to have IPFS running all the time, or have other reasons).

I think only reasonable solution would be not to redirect until known issues are resolved or only redirect requests coming from chrome (until Firefox, Safari support this)

@Gozala Gozala added kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization labels Jul 8, 2020
@Gozala
Copy link
Author
Gozala commented Jul 8, 2020

Can anyone with windows machine check if default browser there handles this properly ?

@Gozala
Copy link
Author
Gozala commented Jul 8, 2020

Found a corresponding Safari bug https://bugs.webkit.org/show_bug.cgi?id=160504 and posted a comment.

@Gozala
Copy link
Author
Gozala commented Jul 8, 2020

Per @rafaelramalho19 it works with default windows browser

image

@thienpow
Copy link

Screenshot 2020-07-12 at 10 11 31 PM

same here... my code look for http://localhost:8080/ipfs/QmWq7GRWzZDKqeHsuCkrMG4cWV4dintmRpewxESjH1rGJR
it would fail to access with safari and firefox, and i have to force it to redirect to https://ipfs.io/ipfs/QmWq7GRWzZDKqeHsuCkrMG4cWV4dintmRpewxESjH1rGJR
this would defeat the purpose of decentralized... and burden the ipfs.io gateway.

@thienpow

This comment has been minimized.

@thienpow
Copy link

Per @rafaelramalho19 it works with default windows browser

image

this is bcos Edge browser is Chromium based... all Chromium based browser is working without problem.

@thienpow
Copy link

another related problem, for orbit-db to connect via ipfs-http-client to go-ipfs

orbitdb/orbitdb#818

and this must set allow-origin to * in order to even work for chromium... and yes only chromium based browser will work. safari wont work either with *

@lidel
Copy link
Member
lidel commented Jul 15, 2020

@thienpow

@thienpow

This comment has been minimized.

@thienpow

This comment has been minimized.

@lidel
Copy link
Member
lidel commented Jul 15, 2020

If you have IPFS Companion installed and enabled it will set up proxy in Firefox and default to subdomain gateway, but go-ipfs 0.5+ at http://127.0.0.1:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR (raw IP) does not redirect on its own.

If you want to make requests to local gateway that do not use subdomains and work in every browser without proxy/extension, make sure you use 127.0.0.1 instead of localhost for now.

@thienpow
Copy link

i don't have companion installed... it's automatic redirect with go-ipfs 0.6.0 for the localhost
and yes 127.0.0.1 won't be redirected

@Asherathe
Copy link

I'm using IPFS Companion with Firefox 80.0.1 and go-ipfs 0.6.0 on Peppermint 10 Respin (Lubuntu-based), and neither localhost:8080 nor 127.0.0.1:8080 work unless I turn off the local gateway. Localhost subdomains do work, regardless of whether the local gateway is on or off.

@jamiehewitt15
Copy link

I'm not sure if this is a related issue, but I'm also having problems access IPFS Localhost from the command line on Windows.

If I run:
git clone http://QmYgyahQoikJEbZEkiubwxm16xjCAZs2RUd1qfuus2Zyeq.ipfs.localhost:8080/
Or:
git clone http://localhost:8080/ipfs/QmYgyahQoikJEbZEkiubwxm16xjCAZs2RUd1qfuus2Zyeq

I get the following error message:
fatal: unable to access 'http://QmYgyahQoikJEbZEkiubwxm16xjCAZs2RUd1qfuus2Zyeq.ipfs.localhost:8080/': Could not resolve host: QmYgyahQoikJEbZEkiubwxm16xjCAZs2RUd1qfuus2Zyeq.ipfs.localhost

However, I have managed to get it working by running:
git clone http://127.0.0.1:8080/ipfs/QmYgyahQoikJEbZEkiubwxm16xjCAZs2RUd1qfuus2Zyeq

@godcong
Copy link
godcong commented Sep 28, 2020

This seems to be the same issue(#7697) as I mentioned
All localhost will be resolved and then redirected
In addition, if it is a local ip address(192.168.xxx.xxx), it seems to be resolved and then redirected.
The remote ip address(192.168.xxx.xxx) will not do this.

@Asherathe
Copy link

I'm on Firefox 81.0 and go-ipfs 0.7.0 now, and no longer having this problem.

@godcong
Copy link
godcong commented Sep 29, 2020

I'm on Firefox 81.0 and go-ipfs 0.7.0 now, and no longer having this problem.

I still have the problem on Firefox 81.0 (64) and windows 10 and go-ipfs 0.8.0-dev, are you using an address like 127.0.0.1:8080/ipfs/xxxx instead of localhost:8080/ipfs/xxxx
These two give me different results

@Asherathe
Copy link

I'm on Firefox 81.0 and go-ipfs 0.7.0 now, and no longer having this problem.

I still have the problem on Firefox 81.0 (64) and windows 10 and go-ipfs 0.8.0-dev, are you using an address like 127.0.0.1:8080/ipfs/xxxx instead of localhost:8080/ipfs/xxxx
These two give me different results

They both work for me now.

@aschmahmann
Copy link

This seems to be the same issue(#7697) as I mentioned

They're not, as @lidel explained that issue is related to the fact that the software you are using doesn't follow HTTP redirects. The suggestion to use an IP address instead of localhost there was simply so there would not be a redirect and so you could deal with the bugs in your video player.

They both work for me now.

@Asherathe are you sure you're testing without IPFS Companion enabled? Everything works fine if IPFS companion is enabled, but if you turn it off in Firefox and then go to localhost:8080/ipns/ipfs.io/ I suspect you'll get an error (at least I do on Windows 10 + Firefox 81)

@Asherathe
Copy link

@Asherathe are you sure you're testing without IPFS Companion enabled? Everything works fine if IPFS companion is enabled, but if you turn it off in Firefox and then go to localhost:8080/ipns/ipfs.io/ I suspect you'll get an error (at least I do on Windows 10 + Firefox 81)

I had reported here before that I was having the same problem with localhost:8080, even though IPFS Companion was enabled. That's no longer the case. That's the main point I was trying to communicate. With IPFS Companion disabled, the problem does still exist. Apologies for confusing things.

@lidel lidel changed the title localhost subdomains do not work on Firefox and Safari localhost subdomains do not work on Safari (macOS) Dec 9, 2022
@lidel lidel added status/blocked Unable to be worked further until needs are met and removed need/triage Needs initial labeling and prioritization labels Dec 9, 2022
@lidel lidel transferred this issue from ipfs/kubo Dec 9, 2022
@lidel
Copy link
Member
lidel commented Dec 14, 2023

Hi, could someone with MacOS Sonoma 14.2 (or later) and either with Safari 17.1.2 and Safari Technology Preview 184 (or later) confirm if this insteed was fixed upstream?

https://bugs.webkit.org/show_bug.cgi?id=160504#c5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) status/blocked Unable to be worked further until needs are met
Projects
None yet
Development

No branches or pull requests

7 participants