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

Jump to bottom

curl does not automatically resolve *.localhost like Chrome does. #9192

Closed
TheKnarf opened this issue Jul 21, 2022 · 4 comments
Closed

curl does not automatically resolve *.localhost like Chrome does. #9192

TheKnarf opened this issue Jul 21, 2022 · 4 comments
Assignees
@bagder
Labels
enhancement name lookup DNS and related tech

Comments

@TheKnarf
Copy link

TheKnarf commented Jul 21, 2022 •
edited

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 bagder added the name lookup DNS and related tech label Jul 21, 2022
@bagder
Copy link
Member

bagder commented Jul 21, 2022

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

  1. 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
Copy link
Member

bagder commented Jul 27, 2022

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

@bagder bagder self-assigned this Aug 11, 2022
bagder added a commit that referenced this issue Aug 11, 2022
@bagder
hostip: resolve *.localhost to 127.0.0.1/::1
58d1292 
Following the footsteps of other clients like Firefox/Chrome.  RFC 6761
says clients SHOULD do this.

Add test 389 to verify.

Reported-by: TheKnarf on github
Fixes #9192
@bagder bagder mentioned this issue Aug 11, 2022
Closed
@bagder bagder closed this as completed in b5c0fe2 Aug 11, 2022
@dfandrich
Copy link
Contributor

dfandrich commented Oct 11, 2022 via email

shouze pushed a commit to gogaille/docker that referenced this issue May 5, 2023
fix(bref): ggll.localhost ip
87b8b11 
see curl/curl@b5c0fe2

see curl/curl#9192
@shouze shouze mentioned this issue May 5, 2023
Merged
tyx pushed a commit to gogaille/docker that referenced this issue May 5, 2023
fix(bref): ggll.localhost ip (#76)
c2d2980 
see curl/curl@b5c0fe2

see curl/curl#9192
@jkobus jkobus mentioned this issue Jan 23, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bagder bagder

Labels
enhancement name lookup DNS and related tech
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

hostip: resolve *.localhost to 127.0.0.1/::1 curl/curl
3 participants
@bagder @TheKnarf @dfandrich