Bug 4235 - Misleading "node name" unknown messages when http_proxy set incorrectly
: Misleading "node name" unknown messages when http_proxy set incorrectly
Status: RESOLVED FIXINSOURCE
Product: pkg
transport
: in97 (0956b5b55a4d)
: ANY/Generic All
: P4 minor (vote)
: ---
Assigned To: johansen
: pkg/transport watcher
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-10-24 15:52 UTC by Alan Coopersmith
Modified: 2009-07-01 16:40 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Alan Coopersmith 2008-10-24 15:52:41 UTC
[I know this is more likely in the underlying python http module, but since
 it took several people quite a while to track this down, at least this bug
 will serve as a hint in the future.]

When http_proxy environment variable is set to an invalid hostname (such as
one of the now-EOL'ed internet proxies on the SWAN), commands such as pkg
refresh and pkg image-update report errors that the IPS repo host is unknown,
even though the host is resolvable via the name service, such as:

% setenv http_proxy http://bad-proxy-host.sfbay.sun.com:8080/
% pfexec pkg refresh
pkg: 0/1 catalogs successfully updated:
    osol-re.sfbay: node name or service name not known
% ping osol-re.sfbay
osol-re.sfbay is alive

It would be exceptionally nice if it could instead print something more like:
     bad-proxy-host.sfbay.sun.com: http_proxy node name not known
Comment 1 johansen 2008-10-27 14:06:10 UTC
Inspection of the urllib2.py module seems to indicate that this really is a
problem in Python and not pkg.  The urllib2.ProxyHandler class gets inserted
into the urllib2 stack.  It will decide look for proxies, and use them if it
can find them.  However, when it does use a proxy, it doesn't include that
information in much of the error handling.  The URLError exception, raised when
name resolution fails, contains only the errno and strerror of the underlying
socket operation's failure.  It doesn't return the url that it tried to open,
so callers are left guessing.  This is why our error message isn't particularly
straight forward.
Comment 2 Danek Duvall 2008-11-14 08:00:45 UTC
*** Bug 4998 has been marked as a duplicate of this bug. ***
Comment 3 johansen 2009-06-23 13:31:54 UTC
This bug is being fixed as part of the transport re-design.  A preliminary
webrev is available from:

http://cr.opensolaris.org/~johansen/webrev-xport-1/
Comment 4 johansen 2009-07-01 16:40:11 UTC
Integrated 1Jul2009 as change set a48bee2a4b2e9c8345c29acea63116acf77dddb3