-
Notifications
You must be signed in to change notification settings - Fork 614
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
Resolve foo.localhost as localhost #477
Comments
The part of the RFC you are referencing is talking about just "localhost". I've seen no standard stating there is such a thing as a subdomain of localhost or how to treat those. If you drop to a command line and run On my own system:
If I edit /etc/hosts and add it as an alias, it works. So either my system resolver (which is not c-ares, this happens to be MacOS at this time) is also broken, or Chrome is doing something special. |
Upon further research, you may actually be encountering non-standard extensions introduced by systemd: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Synthetic%20Records |
but what it says is
? |
Interesting, missed the falling within ".localhost.", wonder why this isn't universally supported then. |
I was extremely surprised when reading that RFC, which seems pretty clear and points at Chrome implementing the correct behavior. |
Chrome implements this on Mac too, it's not Systemd specific. |
From nodejs/undici#1571:
Bug Description
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 this does not seem to work when trying to query the api usingundici
(seereproducible by
below).This seems to break RFC-6761:
So it seems that Chrome resolves
hasura.localhost
as the localhost loopback, while Node.js and in in turn c-ares do not.From a quick look at it,
c-ares/src/lib/ares_getaddrinfo.c
Lines 490 to 499 in e20215a
The text was updated successfully, but these errors were encountered: