Arriccia i nomi host locali su Mac OS X Yosemite

Ho appena aggiornato da Mavericks a Yosemite e ora curlnon riesco a vedere i nomi degli host di loopback.

Configurare un semplice server http per testare:

$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Ora posso colpire localhost: 8000 in Chrome. Posso anche wget it. Ma a ricciolo, questo succede:

$ curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

Tuttavia, questo funziona:

$ curl 127.0.0.1:8000

Ho letto questa risposta sulle impostazioni del proxy wget , ma non ha aiutato, perché funziona:

$ wget --proxy=off localhost:8000

Questo è davvero frustrante, perché ho alcuni nomi host di loopback diversi elencati nel mio /etc/hostsfile in modo da poter sviluppare app localmente e sono abituato a eseguirne il debug con arricciatura.

Ho provato con la versione di arricciatura fornita con osx:

$ curl --version
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz

$ curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

$ curl 127.0.0.1 # works

E ho provato a compilare il ricciolo con brew:

$ /usr/local/Cellar/curl/7.38.0/bin/curl --version
curl 7.38.0 (x86_64-apple-darwin14.0.0) libcurl/7.38.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz

$ /usr/local/Cellar/curl/7.38.0/bin/curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

$ /usr/local/Cellar/curl/7.38.0/bin/curl 127.0.0.1:8000 # works

Ho appena funzionato commentando una delle linee di loopback IPv6 dal mio file / etc / hosts:

#fe80::1%lo0    localhost

Ora tutti i miei nomi host di loopback funzionano, non solo localhost. Mi chiedo che succede?

Alternativa (non richiede sudo o modifica /etc/hosts) - usa sempre ipv4 fino a quando l'arricciatura diventa più intelligente.

$ echo '--ipv4' >> ~/.curlrc

(quindi tutto funzionerà come desiderato)

Prima di tutto, 0.0.0.0è un indirizzo speciale che significa "qualsiasi indirizzo IPv4".

Un socket può essere associato al protocollo IPv4 o IPv6. Se un socket è associato 0.0.0.0, significa che ascolterà qualsiasi IPv4 che tenta di connettersi ad esso e verrà rappresentato come segue:

$ nc -l 0.0.0.0 8085
$ lsof -i4 -Pnl | grep 8085
  nc        23994 [xxx]    3u  IPv4 [xxx]      0t0  TCP *:8085 (LISTEN)

Il *segno è equivalente a 0.0.0.0su IPv4.

Per IPv6:

$ nc -l :: 8085
$ lsof -i6 -Pnl | grep 8085
  nc        24145 [xxx]    3u  IPv6 [xxx]      0t0  TCP *:8085 (LISTEN)

Il *segno è equivalente a ::IPv6, come nelle specifiche ufficiali .

Il motivo è che curltenta di risolvere una localhostvoce casuale /etc/hostse, come menzionato @NickRetallack, quella voce è quella scelta curlquando si risolve localhostnella sua modalità predefinita (presumibilmente IPv6 o IPv4, qualunque cosa si risolva per prima).

Costringendolo a --ipv4modalità, come suggerito @CharlesHebdough, farà curlvolontà localhostdi 127.0.0.1(assumendo non ci sono altre voci IPv4 per localhostin /etc/hosts).

Ogni implementazione si risolverà localhostcome desiderano, quindi perché hai avuto successo intermittente con strumenti diversi.

Per essere il più preciso possibile, usa 127.0.0.1invece di localhost, ma ti legherà a IPv4. localhostti dà la flessibilità di lavorare in entrambi i protocolli IPv6 e IPv4, tuttavia in alcune implementazioni potresti avere problemi, come in quella versione specifica di curl.