Using ProxyPass and ReverseProxyPass within a virtual host to pass on all traffic to an internal webserver ( Apache 1.3 for Oracle Application Server ). Roughly 1 in 10 requests, be it for pages or images, result in ; Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /pls/pls/portal/url/page/blahblahblah Reason: DNS lookup failure for: test.myservernamewashere.com ---- Debug log looks like ; [Wed Aug 18 10:43:21 2004] [debug] mod_cache.c(157): cache: no cache - add cache_in filter and DECLINE [Wed Aug 18 10:43:21 2004] [debug] proxy_http.c(66): proxy: HTTP: canonicalising URL //test.myservernamewashere.com/pls/pls/portal/url/page/blahblahblah [Wed Aug 18 10:43:21 2004] [debug] mod_proxy.c(416): Trying to run scheme_handler [Wed Aug 18 10:43:21 2004] [debug] proxy_http.c(1073): proxy: HTTP: serving URL http://test.myservernamewashere.com/pls/pls/portal/url/page/blahblahblah?menu=m1open [Wed Aug 18 10:43:21 2004] [debug] proxy_http.c(185): proxy: HTTP connecting http://test.myservernamewashere.com/pls/pls/portal/url/page/blahblahblah?menu=m1open to test.myservernamewashere.com:80 [Wed Aug 18 10:43:21 2004] [error] [client 81.144.201.222] proxy: DNS lookup failure for: test.myservernamewashere.com returned by /pls/pls/portal/url/page/blahblahblah, referer: http://test.myservernamewashere.com/portal/page?_pageid=53,393023&_dad=portal&_schema=PORTAL ------ Notes ; Mod cache ( memory ) is enabled. We're not using a DNS server, just /etc/hosts, on Sparc Solaris 9 We're using name based virtual hosts, not ip addressed based The internal server has the same virtual hostname as the external virtual hostname. Full apache config available on request.
Created attachment 12465 [details] patch to ensure the error message is correct
It could be that apache is perfectly correct. But there is an apparent bug: there are two different paths to the same error message, and in one case the name of the server looked up may be misreported. Does the patch help?
hmmm having trouble with the patch ; proxy_http.c: In function `ap_proxy_http_determine_connection': proxy_http.c:197: error: `uri_hostname' undeclared (first use in this function) proxy_http.c:197: error: (Each undeclared identifier is reported only once proxy_http.c:197: error: for each function it appears in.) should it be uri->hostname ?
Yep, you're right. The patch won't fix your problem; it'll just help diagnose where the problem really is (which may or may not be Apache).
Ok, the patch doesn't seem to have made any difference, still getting ; Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: DNS lookup failure: hostname test.myservername.com .... and in the error log for the virtual host ..... [Wed Aug 25 14:15:01 2004] [error] [client 192.168.1.4] proxy: DNS lookup failure: hostname test.myservername.com returned by / We even put the second webserver on the same box, resolving test.myservername.com to it's second ip address, to see if that would work, but we're still getting the dns error every so often.
does hard coding the IP/hostname in /etc/hosts make a difference? are you sure its not something wrong with your DNS server?
No we're not using BIND / DNS at all, just purely the entries in /etc/hosts. It's a solaris box, so it'll be using the local name resolving methods involving resolv.conf etc etc, but I guess the error page on Apache generalises the word "DNS" to mean "any form of name resolving" :) We've still got the problem. We've had to change all proxying to ip address based proxying, which considering our backend boxes are all using virtual hosts, this has caused us major problems ! Mike
The problem is apr_sockaddr_info_get returning some kind of failure. I'm guessing it's an IPV4 vs IPV6 problem, and that either (1) It's actually an APR bug or (2) It's a mismatch between your Apache compile, your APR compile, and your system libs. If you compiled it yourself using configure/make/make install then it's a build error. If you installed a package, then it's an incompatibility - build it yourself or contact your supplier. Next diagnostic step would be to print the value of err returned from apr_sockaddr_info_get in the error message.
That diagnosis sounds promising. We compile the binaries on a compile box which has the full gcc installed. Then the apache directory is copied across to the live production boxes, which doesn't have full gcc, just the gcc libraries. The compile box and production boxes should be identical, but wouldn't surprise me if there were differences :) If you can tell me the best way to get values from apr_sockaddr_info_get that would be great.
This is quite old. Please test/confirm with more recent versions and reopen if needed.