-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Node v0.12: HTTP server with implicit address binding reports addresses in IPv6 format? #9195
Comments
It's dual stack by default, hence why you see the /cc @indutny |
I was hit by this as well after the upgrade. Does this depend on system configuration, or can we safely assume that from now on, IPv4 addresses will be represented this way? |
@pehlert If the system supports IPv6 then yes. |
@trevnorris this code ignores the desired address family, even if one is present since no address was provided. Do you think this is worth updating? |
@cjihrig You're right, that is a strange discrepancy between our documentation and how it operates. Docs say:
Which means I'd expect an IPv4 address. So either a functional change, or a document change is necessary. /cc @indutny |
Also, when started without an explicit address, The change sort of breaks my world, so for now I'll explicitly bind to '0.0.0.0' to coerce the server into IPv4 mode (per the code @cjihrig linked). This stuff would affect #7645's request for docs, too. |
@tjfontaine any opinion on whether this should be a documentation or behavior change? |
Seeing the same behavior. Any update on this issue? |
@joyent/node-coreteam do any of you have a preference on whether we should change the docs to reflect the current behavior (try to bind to IPv6 first), or change the current behavior back to that of 0.10? |
@cjihrig we've been binding to IPv6 by default since the early v0.11 days, so I'm going to say that this should be a doc change. |
@cjihrig @trevnorris @joyent/node-coreteam My opinion is that we might want to reconsider this change. There's more background in a discussion that happened after the changed landed. There are other issues created for the same problem:
I also fixed one in express and one in hapi a few months ago. It's not clear if we have reached the point where we received enough bug reports about it to revert the change, but I think it's worth considering. |
Not sure if reverting is the right approach but refactoring a bit and documenting would be good. |
Adding to the 0.12.1 milestone to make sure we consider this before shipping node v0.12.1. |
@jasnell @cjihrig @trevnorris @misterdjules I just ran into this today. Was going through the express intro docs and was expecting and ipv4 address and received an ipv6 one. Seems to me like this might have fallen by the way side (at least updating the tutorial in express) |
I think this can be closed now. The docs were updated, and now read:
|
@cjihrig I'm still trying to figure out how I get When the updated And if defined behavior is to listen on both IPv4 and IPv6 by default (0.12 does this), how does my IPv4 request get "promoted" to IPv6 when it hits the node.js server, causing Looks like that doc change on |
@mildmojo, I'll try to explain to the best of my understanding. When your server calls As mentioned earlier in this thread, a dual stack is used, meaning that the IPv6 interface can also handle IPv4 connections. When an IPv4 address is received over IPv6, it is prefixed with
@jasnell should the documentation update be backported? |
@cjihrig it definitely should imho. |
@thealphanerd looks like you want nodejs/node@5c7ab96 |
ok cool... that docfix is in the 4.x line, which is where I have been landing stuff. I think that @rvagg has been taking lead on 0.12.x |
Thanks, @cjihrig. I think I might have it now. I didn't recognize "dual stack" as a term of art. So somewhere upstream of Node, maybe at the OS level, the IPv6 interface is a dual stack and will transparently translate IPv4 traffic for IPv6 listeners. Node prefers to bind to IPv6 by default. On an IPv6 platform without a dual stack, IPv4 connections would just fail to connect. OSX happens to be a dual stack environment, so my IPv4 requests go through (translated). As far as Node is concerned, it's bound to IPv6 interfaces, so everything that comes in looks like IPv6 traffic. If that's all true, I'm still a little fuzzy on why |
@thealphanerd |
more than happy to 😄 |
Hey all... just getting back from vacation and catching up. On a quick scan:
|
@mildmojo I believe (but I'm not sure) that |
I'll take it! Thanks for explaining this for me. Cheers! 🍹 |
I bumped into the same issue too! Previously I could connect to Node app with IPv4 (another part of the application can work only with IPv4). Now it fails. If I specify 127.0.0.1 explicitly, then Node listens on port but another app can't establish connection - there is error 'EACCES' even if Node runs with administrative privileges and ports are in range 49152-65535. Is it possible to make a setting to programmatically choose the interface family so that it could work like in previous versions? |
The former is used as an "authority" part of HTTP URLs. The latter -- for listening and connecting. URLs want something like "localhost" but sockets cannot listen on "localhost". Discovered that we cannot use default (i.e., undefined) listening host because older nodejs (e.g., v0.10.25) essentially interpret it as "any IPv4 if possible" while the newer nodejs interpret undefined host as ":: if possible". We now specify "::" explicitly in hope to avoid this difference. Here is one reference explaining the newer behavior: nodejs/node-v0.x-archive#9195 (comment)
For those running on e.g. Fedora 23, check that it's not your |
Could you please reopen this issue? It's not solved. |
@IgorTitov What's not solved? The new behavior is documented and won't change. |
This makes it easier to see what header has an invalid value. PR-URL: nodejs#9195 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
I'm not completely sure what I'm seeing. I first noticed that I was getting different results for
http.IncomingMessage.connection.remoteAddress
between v0.10.36 and v0.12.0 on OSX 10.8.5:If I explicitly bind the server to
127.0.0.1
, v0.12 matches v0.10.36. The docs for http.Server.listen still say "If the hostname is omitted, the server will accept connections directed to any IPv4 address (INADDR_ANY)." I expected to get an IPv4-formatted address from.remoteAddress
.Is this an intended API change? Thanks.
The text was updated successfully, but these errors were encountered: