> -----Original Message-----
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> Sent: Friday, April 04, 2014 12:10 PM
> To: 'Tomcat Users List'
> Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
> not work
>
> > -----Original Message-----
> > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> > Sent: Friday, April 04, 2014 12:04 PM
> > To: 'Tomcat Users List'
> > Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
> > not work
> >
> > > -----Original Message-----
> > > From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > Sent: Friday, April 04, 2014 10:23 AM
> > > To: Tomcat Users List
> > > Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
> > > does not work
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > Jeffrey,
> > >
> > > On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
> > > >> -----Original Message----- From: André Warnier [mailto:aw@ice-
> > > sa.com]
> > > >> Sent: Thursday, April 03, 2014 5:27 PM To:
> > > >> Tomcat Users List Subject: Re: AW: AW:
> > > >> tomcat-connectors-1.2.39-windows-x86_64-iis does not work
> > > >>
> > > >> Christopher Schultz wrote:
> > > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> > > >>>
> > > >>> André,
> > > >>>
> > > >>> On 4/3/14, 3:34 PM, André Warnier wrote:
> > > >>>> Alten, Jessica-Aileen wrote:
> > > >>>>>> -----Ursprüngliche Nachricht----- Von: André Warnier
> > > >>>>>> [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
> > > >>>>>> 2014 15:36 An: Tomcat Users List Betreff: Re: AW:
> > > >>>>>> tomcat-connectors-1.2.39-windows-x86_64-iis does not work
> > > >>>>>>
> > > >>>>>> Alten, Jessica-Aileen wrote:
> > > >>>>>>>> A bit guessing here :
> > > >>>>>>>>
> > > >>>>>>>> You have :
> > > >>>>>>>>> worker.ajp13w.host=localhost
> > > >>>>>>>> and
> > > >>>>>>>>
> > > >>>>>>>>> jk_open_socket::jk_connect.c (735): connect to
> > > >>>>>>>>> 0.0.0.0:8009
> > > >>>>>> failed
> > > >>>>>>>>> (errno=49)
> > > >>>>>>>> is "localhost" == 0.0.0.0 ?
> > > >>>>>>>>
> > > >>>>>>>> From the point of view of mod_jk/isapi, should it not be
> > > >>>>>> "127.0.0.1" ?
> > > >>>>>>> Your answer points to the right direction. 0.0.0.0
> > > >>>>>>> means: any configured IPv4-Address on this computer, see
> > > >>>>>>>
> > > >>>>>>> http://serverfault.com/questions/78048/whats-the-
> difference-
> > > >>
> > > >>>>>>>
> > > betwee
> > > >>>>>>> n-
> > > >>> ip
> > > >>>>>>> -addre ss-0-0-0-0-and-127-0-0-1
> > > >>>>>>>
> > > >>>>>>> In principle this is ok at first. The Ajp13 Connector was
> > > >>>>>>> configured in server.xml to listen at any IPv4 address on
> > port
> > > >>>>>>> 8009 - which is the default setting.
> > > >>>>>>> But the connector can't find any suitable
> > > >>>>>> address.
> > > >>>>>>> The problem is: The new Tomcat-Connector can't parse
> > > >>>>>>> "worker.ajp13w.host=localhost", instead localhost must be
> > > >> replaced
> > > >>>>>>> with "127.0.0.1", this works!
> > > >>>>>>>
> > > >>>>>>> In my eyes this is a big fat bug, because most
> documentation
> > > >>>>>>> on workers use "localhost". localhost is actually the
> > > >>>>>>> default for
> > > >> the
> > > >>>>>>> "host" connection directive.
> > > >>>>>>>
> > > >>>>>>> The new worker directive "prefer_ipv6" doesn't change this
> > > >>>>>>> behavior.
> > > >>>>>>>
> > > >>>>>> Hi.
> > > >>>>>>
> > > >>>>>> Can you please really check this ?
> > > >>>>>>
> > > >>>>>> Open a command window on that server, and do "ping
> localhost".
> > > It
> > > >>>>>> should tell you what it understands by "localhost". Copy and
> > > >>>>>> paste the result here :
> > > >>>>> ping localhost
> > > >>>>>
> > > >>>>> Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32
> Bytes
> > > >>>>> Daten: Antwort von 127.0.0.1: Bytes=32 Zeit<1ms
> > > >>>>> TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
> > Antwort
> > > >>>>> von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128 Antwort von
> 127.0.0.1:
> > > >>>>> Bytes=32 Zeit<1ms TTL=128
> > > >>>>>
> > > >>>>> Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen
> > > >>>>> =
> > > 4,
> > > >>>>> Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
> > Minimum
> > > =
> > > >>>>> 0ms, Maximum = 0ms, Mittelwert = 0ms
> > > >>>>>
> > > >>>>>
> > > >>>> That /is/ bizarre. As far as I know, to resolve hostnames in
> > its
> > > >>>> configuration, mod_jk/isapi is using the OS's resolver
> library,
> > > the
> > > >>>> same as the one "ping" should be using. On the other hand, you
> > > >>>> say that if you have
> > > >>>>
> > > >>>>>>>>> worker.ajp13w.host=localhost
> > > >>>> it doesn't work (mod_jk cannot connect to tomcat), but when
> you
> > > >>>> change this to
> > > >>>>
> > > >>>>>>>>> worker.ajp13w.host=127.0.0.1
> > > >>>> then it works fine.
> > > >>>>
> > > >>>> Ok, another check in a command window (and I assume that you
> > open
> > > >>>> this command window *on the server itself* where mod_jk and
> > > >>>> Tomcat are running, right ?)
> > > >>>>
> > > >>>> test :
> > > >>>>
> > > >>>> 1) telnet localhost 8009
> > > >>>>
> > > >>>> 2) telnet 127.0.0.1 8009
> > > >>>>
> > > >>>> Any difference between these 2 cases ?
> > > >>>>
> > > >>>> If not, then indeed it looks like a mod_jk/isapi_redirect
> > > >>>> 1.2.39 problem.
> > > >>>>
> > > >>>> In any case, you cannot "connect to" 0.0.0.0, as this log line
> > > >>>> would suggest :
> > > >>>>
> > > >>>>>>>>> jk_open_socket::jk_connect.c (735): connect to
> > > >>>>>>>>> 0.0.0.0:8009
> > > >>>>>> failed
> > > >>>
> > > >>> Could this be an interaction between IPv4 and IPv6? Try:
> > > >>>
> > > >>> C:> nslookup localhost
> > > >>>
> > > >>> You might get only 127.0.0.1 or you might also get :: (or
> > > >>> something equivalent). I'm not sure why it wasn't happening
> with
> > > >>> earlier versions of mod_jk (which?).
> > > >>>
> > > >> (versions : her first post mentioned the versions she was
> > > >> comparing)
> > > >>
> > > >> I previously asked Jessica-Aileen to do a "ping localhost" on
> the
> > > >> machine, see results above. It definitiely pings 127.0.0.1 ..
> > > >> (assuming it was done on the same machine)
> > > >>
> > > >> And I don't think that nslookup uses the local resolver. When
> I'm
> > > >> doing that on my Windows laptop, for "localhost" it responds
> "not
> > > >> found" (in many more German words)
> > > >>
> > > >> C:\Dokumente und Einstellungen\aw>nslookup localhost Server:
> > > >> fire-see.localdomain Address: 192.168.245.253
> > > >>
> > > >> *** localhost wurde von fire-see.localdomain nicht gefunden:
> > > >> Non- existent domain
> > > >>
> > > >> On the other hand, it does this (spot the difference..):
> > > >>
> > > >> C:\Dokumente und Einstellungen\aw>nslookup localhost. Server:
> > > >> fire-see.localdomain Address: 192.168.245.253
> > > >>
> > > >> Name: localhost Address: 127.0.0.1
> > > >>
> > > >> (But that of course could be the "localhost" of my DNS server,
> > > >> since it happens to be a Linux box running dnsmasq, and it has
> > that
> > > >> name
> > > in
> > > >> it's own hosts file.)
> > > >>
> > > > This result is understandable, as the nslookup tool is a DNS
> > > > resolver tool. It's designed to query the DNS system directly,
> > > > avoiding the systems resolver and any caching. Not exactly sure
> > > > why it resolves "localhost.", but adding the final period tells
> it
> > > > not to append the default domain. In other words, localhost. Is
> a
> > > > top-
> > level domain.
> > > > Perhaps there is a special case built into the DNS system for
> that.
> > > > The difference here is that the resolver is going to search DNS
> > > > and the local hosts table, usually with the local hosts table
> > > > (/etc/hosts in *nix) taking precedence. I've not followed the
> > > > complete thread,
> > > but
> > > > if the server is a *nix implementation, the better diag tool
> might
> > > > be dig. And yes, I would not expect the address 0.0.0.0 on a
> > > > client to connect to the localhost. That is a special case
> > > > address
> > meaning
> > > > "local network".
> > > > If anything, it would be sending packets out the NIC card, not
> via
> > > > loopback.
> > >
> > > 0.0.0.0 means "all IPv4 interfaces available" and only applies for
> > > binding a server socket. You can never connect to "0.0.0.0" as a
> > > client.
> > >
> > Chris -
> > It actually has a different meaning based on use. For binding to a
> > socket in the local IP stack, it means what you say.
> > In the routing table, it means the default route. In
> > firewalls/routers, it probably means something completely different.
> > When used as a destination address, it means what I said. How the IP
> > stack/hardware deals with it is dependent on the implementation. The
> > RFCs specify that it should be treated the same as the broadcast
> > address, but local network only, and not routable. That may be for
> > received packets only, as I've seen other references that it should
> > never be used on-the-wire, unless as the source address in protocols
> > like DHCP.
> > In any event, definitely not expect the 0.0.0.0. address to get any
> > response, either local host or otherwise.
> > For the OP's specific problem, s/he need to see how "localhost" is
> > resolving. Most systems define it in the local "hosts" file, either
> > /etc/hosts (*nix) or c:\Windows\system32\etc\hosts. Not sure for
> > other systems.
> > Jeff
> Make that C:\Windows\system32\drivers\etc\hosts.
> I did a test and it appeared that ping didn't rely on the entry being
> there, but it could have been a cached result.
> Jeff
Bad test on my part. I did the above by removing the entry from the hosts file.
Apparently DNS will still resolve it from the DNS server, but not sure how it
decides on the address to send.
If you change the address in the hosts file and then ping, ping will use the
hosts file address, but you'll get your responses from 172.0.0.1. (All tests
done without rebooting on Windows.)
