You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by bu...@apache.org on 2003/02/27 19:37:18 UTC
DO NOT REPLY [Bug 10807] -
Handle virtual hosts, relative urls, multi-homing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10807>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10807
Handle virtual hosts, relative urls, multi-homing
------- Additional Comments From becke@u.washington.edu 2003-02-27 18:37 -------
I'd like to go ahead and tackle this one, but I need a little clarification.
Does the following correctly describe what we want?
- we want to perform a get on www.google.com, let's say www.google.com has X > 1
IP addresses
- we want to specify which IP address x to actually connect to
- we want www.google.com in the Http header instead of x
If this is the case, it sounds like we may want support for custom DNS
resolution. Though this might be a little more than is needed for this simple
case I think that is what it boils down to.
Mike
Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative
urls, multi-homing
Posted by Michael Becke <be...@u.washington.edu>.
> 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.
I'm not exactly sure how it would get implemented but it could be on a
per connection basis. It would not have to be global. It will really
just depend if we can do it without too many API changes.
> 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.
Interesting, not something I had thought of. This could certainly be
done if we were using a pluggable DNS resolution method.
Mike
Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative
urls, multi-homing
Posted by Mike Moran <mi...@mac.com>.
Michael Becke wrote:
>> 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) :-)
Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative
urls, multi-homing
Posted by Michael Becke <be...@u.washington.edu>.
> 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.
Mike
Re: DO NOT REPLY [Bug 10807] - Handle virtual hosts, relative
urls, multi-homing
Posted by Mike Moran <mi...@mac.com>.
bugzilla@apache.org wrote:
[ ... ]
>
>
>------- Additional Comments From becke@u.washington.edu 2003-02-27 18:37 -------
>I'd like to go ahead and tackle this one, but I need a little clarification.
>Does the following correctly describe what we want?
>
>- we want to perform a get on www.google.com, let's say www.google.com has X > 1
>IP addresses
>- we want to specify which IP address x to actually connect to
>- we want www.google.com in the Http header instead of x
>
>If this is the case, it sounds like we may want support for custom DNS
>resolution. Though this might be a little more than is needed for this simple
>case I think that is what it boils down to.
>
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>"?
--
Mike