hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Blavins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1309) UnknownHostException if DefaultHttpClient asked to handle HttpRequest whose host name includes a port
Date Wed, 30 Jan 2013 21:03:12 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566894#comment-13566894
] 

Ian Blavins commented on HTTPCLIENT-1309:
-----------------------------------------

G'day

Its a subtle form of your suggestion. I already have the HttpRequest as 'request' and I do:

Header hostHeader = request.getFirstHeader("Host");
String hostName = hostHeader.getValue();
HttpHost target = new HttpHost(hostName);

If the Host in the request includes a port, as mine did, then the hostName in the HttpHost
will too and this will lead to the UnknownHostException downstream.

So User Error.

That being said:

1) if HttpHost is going to do DNS resolution on the hostname as is, maybe it should reject
a host name that includes a port or maybe internally it could treat a new HttpHost(hostName)
call as a new HttpHost(hostName-less-port, port) call if the host name contains a port

2) To avoid the problem, however it arises, org.apache.http.impl.conn.SystemDefaultDnsResolver
could, in its .resolve method, silently remove any port from the host name; better this than
an exception

3) Or one might ask why the DefaultHttpClient's .execute method needs to be passed an HttpHost
in addition to the HttpRequest when the request contains all the information to make the HttpHost;
if I recall the standard correctly the HttpHost that is needed by .execute is completely determined
by the content of the request. If DefaultHttpClient's execute method made the HttpHost itself
then the possibility of mismatch between the HttpHost and the HttpRequest, which is what caused
this problem, is eliminated; the optional scheme parameter of the HttpHost constructor might
be one reason

Just thoughts. 

I've fixed my code and moved on to the next problem. Thanks for you help.


                
> UnknownHostException if DefaultHttpClient asked to handle HttpRequest whose host name
includes a port
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1309
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1309
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpConn
>    Affects Versions: 4.2.3
>         Environment: Mac OS X 10.6.8  HttpClient 4.2.1 - field above won't let me put
in 4.2.1
>            Reporter: Ian Blavins
>            Priority: Minor
>
> If a DefaultHttpClient is passed, in its .execute(target, request, context) method call,
an HttpRequest whose host name field contains a port suffix (eg 192.168.0.102:8080) then SystemDefaultDnsResolver
will try to resolve the host name plus port and gets an UnknownHostException: java.net.UnknownHostException:
192.168.0.102:8080.
> There appears to be a work around and that is to download the source of SystemDefaultDnsResolver,
make the obvious change to remove any port and then rebuild httpclient-4.2.1.jar. (There is
probably an easier way to present the revised SystemDefaultDnsResolver since its intended
to be replaced by the user developer but I haven't discovered it)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message