Enrolar nomes de hosts locais no Mac OS X Yosemite

Acabei de atualizar o Mavericks para o Yosemite e agora curlnão consigo ver os nomes de host de loopback.

Configure um servidor http simples para testar:

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

Agora eu posso clicar em localhost: 8000 no chrome. Eu posso até acabar com isso. Mas no enrolamento, isso acontece:

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

No entanto, isso funciona:

$ curl 127.0.0.1:8000

Li esta resposta sobre as configurações de proxy do wget , mas não ajudou, porque funciona:

$ wget --proxy=off localhost:8000

Isso é realmente frustrante, porque tenho alguns nomes de host de loopback diferentes listados no meu /etc/hostsarquivo para que eu possa desenvolver aplicativos localmente e estou acostumado a depurá-los com curl.

Eu tentei com a versão do curl que vem com 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 eu tentei compilar curl com 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

Acabei de fazê-lo comentando uma das linhas de loopback IPv6 do meu arquivo / etc / hosts:

#fe80::1%lo0    localhost

Agora, todos os meus nomes de host de loopback funcionam, não apenas localhost. Eu me pergunto o que há com isso?

Alternativa (não requer sudo ou modificação /etc/hosts) - sempre use o ipv4 até que a ondulação fique mais inteligente.

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

(tudo funcionará como desejado)

Primeiro de tudo, 0.0.0.0é um endereço especial que significa "qualquer endereço IPv4".

Um soquete pode ser vinculado ao protocolo IPv4 ou IPv6. Se um soquete estiver vinculado 0.0.0.0, isso significa que ele ouvirá qualquer IPv4 tentando conectar-se a ele e será representado da seguinte forma:

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

O *sinal é equivalente ao 0.0.0.0IPv4.

Para IPv6:

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

O *sinal é equivalente ao ::IPv6, como na especificação oficial .

O motivo é que curltenta resolver uma localhostentrada aleatória /etc/hostse, como o @NickRetallack mencionou, essa entrada é a escolhida curlao resolver localhostno modo padrão (supostamente IPv6 ou IPv4, o que resolver primeiro).

Forçando-o no --ipv4modo, como @CharlesHebdough sugeriu, fará curldeterminação localhostpara 127.0.0.1(assumindo que não há outras entradas IPv4 para localhostnos /etc/hosts).

Cada implementação será resolvida localhostcomo desejarem, daí o motivo pelo qual você teve sucesso intermitente com diferentes ferramentas.

Para ser o mais preciso possível, use no 127.0.0.1lugar do host local, mas ele o vinculará ao IPv4. localhostoferece a flexibilidade de trabalhar nos protocolos IPv6 e IPv4; no entanto, em algumas implementações você pode ter problemas, como nessa versão específica do curl.