curl does not automatically resolve `*.localhost` like Chrome does.

[TheKnarf]

I did this

In my local development env I got Hasura running and responding on hasura.localhost. This works fine in Chrome, I can open the web UI and do stuff from there. However when querying it get the following error

$ curl -g \
-X POST \
-H "Content-Type: application/json" \
-d '{"query":"query MyQuery { user { id email } }"}' \
http://hasura.localhost/v1/graphql

curl: (6) Could not resolve host: hasura.localhost

This seems to break RFC-6761:

Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

So it seems that Chrome resolves hasura.localhost as the localhost loopback, while curl does not.

Now there is a simple fix for my use case, I can simply add --resolve hasura.localhost:80:127.0.0.1 to my curl command and it works fine. However this should not be necessary according to RFC-6761.

I expected the following

To get an result from the endpoint without having to add --resolve.

curl/libcurl version

curl -V
curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

operating system

uname -a
Darwin Mbp13arm.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T8101 arm64

[bagder]

Name resolution APIs and libraries SHOULD recognize localhost names

I would argue that libcurl is not a name resolution API or library, but it uses such APIs and clearly they don't adhere to that RFC.

We could of course still special-case those names like we do with localhost, but where do we draw the line? We also don't special case .onion nor .invalid etc.

[TheKnarf]

2. Application software MAY recognize localhost names as special, or
   MAY pass them to name resolution APIs as they would for other
   domain names.

Since the name resolution API curl uses doesn't handle it properly (at least MacOS does not) I would say it is useful for curl to handle it itself. However where you draw the line I guess is up to you.

[bagder]

I suppose the fact that Firefox and Chrome do this could be reason enough.

[dfandrich]

On Thu, Jul 21, 2022 at 10:15:16AM -0700, TheKnarf wrote: Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

curl is not a name resolution API. Why do you think this is a curl issue and not an issue with the name resolution API curl is using?

[EloB]

@bagder Since this is closed and locked.
#11104

I suppose the fact that Firefox and Chrome do this could be reason enough.

Most operating system does this by default now but they respect the /etc/hosts file or what the DNS actually replies. Also Chrome and Firefox does that. Only returns 127.0.0.1 if it's not set in DNS server. Tried both version 7-8 and they doesn't behave how other software implemented this.

Isn't better to mimic that behaviour instead?

curl is not a name resolution API. Why do you think this is a curl issue and not an issue with the name resolution API curl is using?

I agree with this.