I would support addition regardless, but then that's just me. I assume by "custom DNS resolution" you mean passing in the resolved values eg the HttpClient library is told: "here's the Name/IP mapping, do a GET to this IP with this Host: <Name>"?
I was thinking more along the lines of an interface that would provide DNS resolution. This interface would be used by HttpConnection when opening connections. In general DNS names would be used everywhere except for when creating sockets.
That would also suffice. If possible, I would prefer to pass an implementation of the interface in to HttpConnection upon creation rather than have it as a global setting, but I presume that's easier anyway.
One other thing is that, currently, as a side-effect of using the Socket(DNS name, ...) constructor, the DNS lookup and Socket connection processes seem to be rolled into one. I was wondering if it is worthwhile setting a separate timeout for DNS lookup? As it stands, if DNS becomes slow for some reason then, even if the remote server is responding quickly, you'll get exceptions. Most people wouldn't care, but it would be nice to be able to set a longer timout for DNS responses if you happened to know they sometimes take a while. This would also allow some leeway for an implementation of this DNS interface to do retries internally without worrying about a `connection' timeout externally.
-- Mike (moran) :-)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
