the non-proxy path in LWP::Protocol::HTTP::request has
$host = $url->host;
so it looks like the destination is always taken from the uri
now maybe setting the proxy will do what I want, but does that
have downsides in that the destination won't be a proxy ?
Here's the background.
We use a set of LWP-based scripts, each of which performs a login
to one of our sites. The login status and time is sent to our monitoring
system and an alert generated if the login did not behave as expected,
or the login time was too long. This merely identifies a problem
which could come from the web-server, application server, database,
network etc.
In one case the uri takes you directly to the page with the login form,
but in other cases redirects, and/or cookies and/or javascript is involved.
So I want to replace these scripts with one based on WWW::Mechanize
which makes the code a lot simpler. Of course we still have to manually
code for the effects of any javascript.
Some of the sites to be tested are behind a load-balancer which is normally
configured for sticky connections, i.e. connections from the testing host
are directed to the same cluster member. We still want to test the load-
balanced uri, in case it has problems, but it would be really good to
individually test each cluster member.
We can do that with the Blackboard servers, as they each run just one site,
so a uri of "https://$HOSTNAME/webapps/login/"; does work.
However other web-servers are running multiple sites, so we want to be
able to explicitly specify the ip-address/hostname the connection is
made to.
I believe WWW::Mechanize makes connections thru LWP::UserAgent.
We always use https for login, but it would be good if http also worked.
Is it possible to currently do what I need or would it be hard to extend
the code to support this functionaltity ?
cheers
Danny Thomas
While /etc/host entries could be used, I think that's really gross,
particularly
on a monitoring server which is doing a mix of tests to many hosts. You
don't want the ping test of the load-balanced service directed to one of
the cluster members.
