> -----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
