| LWP::UserAgent - Web user agent class |
LWP::UserAgent - Web user agent class
use strict; use warnings; use LWP::UserAgent ();
my $ua = LWP::UserAgent->new; $ua->timeout(10); $ua->env_proxy;
my $response = $ua->get('http://example.com');
if ($response->is_success) {
print $response->decoded_content; # or whatever
}
else {
die $response->status_line;
}
The the LWP::UserAgent manpage is a class implementing a web user agent. the LWP::UserAgent manpage objects can be used to dispatch web requests.
In normal use the application creates an the LWP::UserAgent manpage object, and then configures it with values for timeouts, proxies, name, etc. It then creates an instance of the HTTP::Request manpage for the request that needs to be performed. This request is then passed to one of the request method the UserAgent, which dispatches it using the relevant protocol, and returns a the HTTP::Response manpage object. There are convenience methods for sending the most common request types: get in the LWP::UserAgent manpage, head in the LWP::UserAgent manpage, post in the LWP::UserAgent manpage, put in the LWP::UserAgent manpage and delete in the LWP::UserAgent manpage. When using these methods, the creation of the request object is hidden as shown in the synopsis above.
The basic approach of the library is to use HTTP-style communication for all protocol schemes. This means that you will construct the HTTP::Request manpage objects and receive the HTTP::Response manpage objects even for non-HTTP resources like gopher and ftp. In order to achieve even more similarity to HTTP-style communications, gopher menus and file directories are converted to HTML documents.
The following constructor methods are available:
my $ua2 = $ua->clone;
Returns a copy of the the LWP::UserAgent manpage object.
CAVEAT: Please be aware that the clone method does not copy or clone your
cookie_jar attribute. Due to the limited restrictions on what can be used
for your cookie jar, there is no way to clone the attribute. The cookie_jar
attribute will be undef in the new object instance.
my $ua = LWP::UserAgent->new( %options )
This method constructs a new the LWP::UserAgent manpage object and returns it. Key/value pair arguments may be provided to set up the initial state. The following options correspond to attribute methods described below:
KEY DEFAULT
----------- --------------------
agent "libwww-perl/#.###"
from undef
conn_cache undef
cookie_jar undef
default_headers HTTP::Headers->new
local_address undef
ssl_opts { verify_hostname => 1 }
max_size undef
max_redirect 7
parse_head 1
protocols_allowed undef
protocols_forbidden undef
requests_redirectable ['GET', 'HEAD']
timeout 180
proxy undef
no_proxy []
The following additional options are also accepted: If the env_proxy option
is passed in with a true value, then proxy settings are read from environment
variables (see env_proxy in the LWP::UserAgent manpage). If env_proxy isn't provided, the
PERL_LWP_ENV_PROXY environment variable controls if
env_proxy in the LWP::UserAgent manpage is called during initialization. If the
keep_alive option is passed in, then a LWP::ConnCache is set up (see
conn_cache in the LWP::UserAgent manpage). The keep_alive value is passed on as the
total_capacity for the connection cache.
proxy must be set as an arrayref of key/value pairs. no_proxy takes an
arrayref of domains.
The settings of the configuration attributes modify the behaviour of the the LWP::UserAgent manpage when it dispatches requests. Most of these can also be initialized by options passed to the constructor method.
The following attribute methods are provided. The attribute value is left unchanged if no argument is given. The return value from each method is the old attribute value.
my $agent = $ua->agent;
$ua->agent('Checkbot/0.4 '); # append the default to the end
$ua->agent('Mozilla/5.0');
$ua->agent(""); # don't identify
Get/set the product token that is used to identify the user agent on
the network. The agent value is sent as the User-Agent header in
the requests.
The default is a string of the form libwww-perl/#.###, where #.### is
substituted with the version number of this library.
If the provided string ends with space, the default libwww-perl/#.###
string is appended to it.
The user agent string should be one or more simple product identifiers
with an optional version number separated by the / character.
my $cache_obj = $ua->conn_cache;
$ua->conn_cache( $cache_obj );
Get/set the the LWP::ConnCache manpage object to use. See the LWP::ConnCache manpage for details.
my $jar = $ua->cookie_jar;
$ua->cookie_jar( $cookie_jar_obj );
Get/set the cookie jar object to use. The only requirement is that
the cookie jar object must implement the extract_cookies($response) and
add_cookie_header($request) methods. These methods will then be
invoked by the user agent as requests are sent and responses are
received. Normally this will be a the HTTP::Cookies manpage object or some
subclass.
The default is to have no cookie jar, i.e. never automatically add
Cookie headers to the requests.
Shortcut: If a reference to a plain hash is passed in, it is replaced with an instance of the HTTP::Cookies manpage that is initialized based on the hash. This form also automatically loads the the HTTP::Cookies manpage module. It means that:
$ua->cookie_jar({ file => "$ENV{HOME}/.cookies.txt" });
is really just a shortcut for:
require HTTP::Cookies;
$ua->cookie_jar(HTTP::Cookies->new(file => "$ENV{HOME}/.cookies.txt"));
my $creds = $ua->credentials();
$ua->credentials( $netloc, $realm );
$ua->credentials( $netloc, $realm, $uname, $pass );
$ua->credentials("www.example.com:80", "Some Realm", "foo", "secret");
Get/set the user name and password to be used for a realm.
The $netloc is a string of the form <host>:<port>. The username and
password will only be passed to this server.
$ua->default_header( $field );
$ua->default_header( $field => $value );
$ua->default_header('Accept-Encoding' => scalar HTTP::Message::decodable());
$ua->default_header('Accept-Language' => "no, en");
This is just a shortcut for
$ua->default_headers->header( $field => $value ).
my $headers = $ua->default_headers;
$ua->default_headers( $headers_obj );
Get/set the headers object that will provide default header values for any requests sent. By default this will be an empty the HTTP::Headers manpage object.
my $from = $ua->from;
$ua->from('foo@bar.com');
Get/set the email address for the human user who controls
the requesting user agent. The address should be machine-usable, as
defined in RFC2822. The from value
is sent as the From header in the requests.
The default is to not send a From header. See
default_headers in the LWP::UserAgent manpage for the more general interface that allow
any header to be defaulted.
my $address = $ua->local_address;
$ua->local_address( $address );
Get/set the local interface to bind to for network connections. The interface
can be specified as a hostname or an IP address. This value is passed as the
LocalAddr argument to the IO::Socket::INET manpage.
my $max = $ua->max_redirect;
$ua->max_redirect( $n );
This reads or sets the object's limit of how many times it will obey redirection responses in a given request cycle.
By default, the value is 7. This means that if you call request in the LWP::UserAgent manpage
and the response is a redirect elsewhere which is in turn a
redirect, and so on seven times, then LWP gives up after that seventh
request.
my $size = $ua->max_size;
$ua->max_size( $bytes );
Get/set the size limit for response content. The default is undef,
which means that there is no limit. If the returned response content
is only partial, because the size limit was exceeded, then a
Client-Aborted header will be added to the response. The content
might end up longer than max_size as we abort once appending a
chunk of data makes the length exceed the limit. The Content-Length
header, if present, will indicate the length of the full content and
will normally not be the same as length($res->content).
my $bool = $ua->parse_head;
$ua->parse_head( $boolean );
Get/set a value indicating whether we should initialize response headers from the <head> section of HTML documents. The default is true. Do not turn this off unless you know what you are doing.
my $aref = $ua->protocols_allowed; # get allowed protocols
$ua->protocols_allowed( \@protocols ); # allow ONLY these
$ua->protocols_allowed(undef); # delete the list
$ua->protocols_allowed(['http',]); # ONLY allow http
By default, an object has neither a protocols_allowed list, nor a
protocols_forbidden in the LWP::UserAgent manpage list.
This reads (or sets) this user agent's list of protocols that the request methods will exclusively allow. The protocol names are case insensitive.
For example: $ua->protocols_allowed( [ 'http', 'https'] );
means that this user agent will allow only those protocols,
and attempts to use this user agent to access URLs with any other
schemes (like ftp://...) will result in a 500 error.
Note that having a protocols_allowed list causes any
protocols_forbidden in the LWP::UserAgent manpage list to be ignored.
my $aref = $ua->protocols_forbidden; # get the forbidden list
$ua->protocols_forbidden(\@protocols); # do not allow these
$ua->protocols_forbidden(['http',]); # All http reqs get a 500
$ua->protocols_forbidden(undef); # delete the list
This reads (or sets) this user agent's list of protocols that the request method will not allow. The protocol names are case insensitive.
For example: $ua->protocols_forbidden( [ 'file', 'mailto'] );
means that this user agent will not allow those protocols, and
attempts to use this user agent to access URLs with those schemes
will result in a 500 error.
my $aref = $ua->requests_redirectable;
$ua->requests_redirectable( \@requests );
$ua->requests_redirectable(['GET', 'HEAD',]); # the default
This reads or sets the object's list of request names that
redirect_ok in the LWP::UserAgent manpage will allow redirection for. By default, this
is ['GET', 'HEAD'], as per RFC 2616.
To change to include POST, consider:
push @{ $ua->requests_redirectable }, 'POST';
my $bool = $ua->send_te;
$ua->send_te( $boolean );
If true, will send a TE header along with the request. The default is
true. Set it to false to disable the TE header for systems who can't
handle it.
my $bool = $ua->show_progress;
$ua->show_progress( $boolean );
Get/set a value indicating whether a progress bar should be displayed on the terminal as requests are processed. The default is false.
my @keys = $ua->ssl_opts;
my $val = $ua->ssl_opts( $key );
$ua->ssl_opts( $key => $value );
Get/set the options for SSL connections. Without argument return the list
of options keys currently set. With a single argument return the current
value for the given option. With 2 arguments set the option value and return
the old. Setting an option to the value undef removes this option.
The options that LWP relates to are:
verify_hostname => $boolThis option is initialized from the PERL_LWP_SSL_VERIFY_HOSTNAME environment
variable. If this environment variable isn't set; then verify_hostname
defaults to 1.
SSL_ca_file => $pathPERL_LWP_SSL_CA_FILE and HTTPS_CA_FILE in order.
SSL_ca_path => $pathPERL_LWP_SSL_CA_PATH and HTTPS_CA_DIR in order.
Other options can be set and are processed directly by the SSL Socket implementation in use. See the IO::Socket::SSL manpage or the Net::SSL manpage for details.
The libwww-perl core no longer bundles protocol plugins for SSL. You will need to install the LWP::Protocol::https manpage separately to enable support for processing https-URLs.
my $secs = $ua->timeout;
$ua->timeout( $secs );
Get/set the timeout value in seconds. The default value is 180 seconds, i.e. 3 minutes.
The request is aborted if no activity on the connection to the server
is observed for timeout seconds. This means that the time it takes
for the complete transaction and the request in the LWP::UserAgent manpage method to
actually return might be longer.
When a request times out, a response object is still returned. The response will have a standard HTTP Status Code (500). This response will have the ``Client-Warning'' header set to the value of ``Internal response''. See the get in the LWP::UserAgent manpage method description below for further details.
The following methods set up when requests should be passed via a proxy server.
$ua->env_proxy;
Load proxy settings from *_proxy environment variables. You might
specify proxies like this (sh-syntax):
gopher_proxy=http://proxy.my.place/ wais_proxy=http://proxy.my.place/ no_proxy="localhost,example.com" export gopher_proxy wais_proxy no_proxy
csh or tcsh users should use the setenv command to define these
environment variables.
On systems with case insensitive environment variables there exists a
name clash between the CGI environment variables and the HTTP_PROXY
environment variable normally picked up by env_proxy. Because of
this HTTP_PROXY is not honored for CGI scripts. The
CGI_HTTP_PROXY environment variable can be used instead.
$ua->no_proxy( @domains );
$ua->no_proxy('localhost', 'example.com');
$ua->no_proxy(); # clear the list
Do not proxy requests to the given domains. Calling no_proxy without
any domains clears the list of domains.
$ua->proxy(\@schemes, $proxy_url)
$ua->proxy(['http', 'ftp'], 'http://proxy.sn.no:8001/');
# For a single scheme:
$ua->proxy($scheme, $proxy_url)
$ua->proxy('gopher', 'http://proxy.sn.no:8001/');
# To set multiple proxies at once:
$ua->proxy([
ftp => 'http://ftp.example.com:8001/',
[ 'http', 'https' ] => 'http://http.example.com:8001/',
]);
Set/retrieve proxy URL for a scheme.
The first form specifies that the URL is to be used as a proxy for
access methods listed in the list in the first method argument,
i.e. http and ftp.
The second form shows a shorthand form for specifying proxy URL for a single access scheme.
The third form demonstrates setting multiple proxies at once. This is also the only form accepted by the constructor.
Handlers are code that injected at various phases during the processing of requests. The following methods are provided to manage the active handlers:
$ua->add_handler( $phase => \&cb, %matchspec )
Add handler to be invoked in the given processing phase. For how to
specify %matchspec see Matching in the HTTP::Config manpage.
The possible values $phase and the corresponding callback signatures are:
This handler needs to return a TRUE value to be called again for subsequent chunks for the same request.
The handler might set the $response->{default_add_content} value to
control if any received data should be added to the response object
directly. This will initially be false if the $ua->request() method
was called with a $content_file or $content_cb argument; otherwise true.
The method can assign a new request object to $_[0] to replace the
request that is sent fully.
The return value from the callback is ignored. If an exception is raised it will abort the request and make the request method return a ``400 Bad request'' response.
request_prepare and other standard
initialization of the request. This can be used to set up headers
and attributes that the request_prepare handler depends on. Proxy
initialization should take place here; but in general don't register
handlers for this phase.
The response_header and response_data handlers will not be
invoked for this response, but the response_done will be.
$ua->request after response_done. If the
handler returns an the HTTP::Request manpage object we'll start over with processing
this request instead.
For all of these, $handler is a code reference to the handler that
is currently being run.
$ua->get_my_handler( $phase, %matchspec );
$ua->get_my_handler( $phase, %matchspec, $init );
Will retrieve the matching handler as hash ref.
If $init is passed as a true value, create and add the
handler if it's not found. If $init is a subroutine reference, then
it's called with the created handler hash as argument. This sub might
populate the hash with extra fields; especially the callback. If
$init is a hash reference, merge the hashes.
$ua->handlers( $phase, $request )
$ua->handlers( $phase, $response )
Returns the handlers that apply to the given request or response at the given processing phase.
$ua->remove_handler( undef, %matchspec );
$ua->remove_handler( $phase, %matchspec );
$ua->remove_handlers(); # REMOVE ALL HANDLERS IN ALL PHASES
Remove handlers that match the given %matchspec. If $phase is not
provided, remove handlers from all phases.
Be careful as calling this function with %matchspec that is not
specific enough can remove handlers not owned by you. It's probably
better to use the set_my_handler in the LWP::UserAgent manpage method instead.
The removed handlers are returned.
$ua->set_my_handler( $phase, $cb, %matchspec );
$ua->set_my_handler($phase, undef); # remove handler for phase
Set handlers private to the executing subroutine. Works by defaulting
an owner field to the %matchspec that holds the name of the called
subroutine. You might pass an explicit owner to override this.
If $cb is passed as undef, remove the handler.
The methods described in this section are used to dispatch requests via the user agent. The following request methods are provided:
my $res = $ua->delete( $url );
my $res = $ua->delete( $url, $field_name => $value, ... );
This method will dispatch a DELETE request on the given URL. Additional
headers and content options are the same as for the get in the LWP::UserAgent manpage
method.
This method will use the DELETE() function from the HTTP::Request::Common manpage
to build the request. See the HTTP::Request::Common manpage for a details on
how to pass form content and other advanced features.
my $res = $ua->get( $url );
my $res = $ua->get( $url , $field_name => $value, ... );
This method will dispatch a GET request on the given URL. Further
arguments can be given to initialize the headers of the request. These
are given as separate name/value pairs. The return value is a
response object. See the HTTP::Response manpage for a description of the
interface it provides.
There will still be a response object returned when LWP can't connect to the server specified in the URL or when other failures in protocol handlers occur. These internal responses use the standard HTTP status codes, so the responses can't be differentiated by testing the response status code alone. Error responses that LWP generates internally will have the ``Client-Warning'' header set to the value ``Internal response''. If you need to differentiate these internal responses from responses that a remote server actually generates, you need to test this header value.
Fields names that start with ``:'' are special. These will not initialize headers of the request but will determine how the response content is treated. The following special field names are recognized:
:content_file => $filename
:content_cb => \&callback
:read_size_hint => $bytes
If a $filename is provided with the :content_file option, then the
response content will be saved here instead of in the response
object. If a callback is provided with the :content_cb option then
this function will be called for each chunk of the response content as
it is received from the server. If neither of these options are
given, then the response content will accumulate in the response
object itself. This might not be suitable for very large response
bodies. Only one of :content_file or :content_cb can be
specified. The content of unsuccessful responses will always
accumulate in the response object itself, regardless of the
:content_file or :content_cb options passed in. Note that errors
writing to the content file (for example due to permission denied
or the filesystem being full) will be reported via the Client-Aborted
or X-Died response headers, and not the is_success method.
The :read_size_hint option is passed to the protocol module which
will try to read data from the server in chunks of this size. A
smaller value for the :read_size_hint will result in a higher
number of callback invocations.
The callback function is called with 3 arguments: a chunk of data, a
reference to the response object, and a reference to the protocol
object. The callback can abort the request by invoking die(). The
exception message will show up as the ``X-Died'' header field in the
response returned by the get() function.
my $res = $ua->head( $url );
my $res = $ua->head( $url , $field_name => $value, ... );
This method will dispatch a HEAD request on the given URL.
Otherwise it works like the get in the LWP::UserAgent manpage method described above.
my $bool = $ua->is_protocol_supported( $scheme );
You can use this method to test whether this user agent object supports the
specified scheme. (The scheme might be a string (like http or
ftp) or it might be an the URI manpage object reference.)
Whether a scheme is supported is determined by the user agent's
protocols_allowed or protocols_forbidden lists (if any), and by
the capabilities of LWP. I.e., this will return true only if LWP
supports this protocol and it's permitted for this particular
object.
my $bool = $ua->is_online;
Tries to determine if you have access to the Internet. Returns 1 (true)
if the built-in heuristics determine that the user agent is
able to access the Internet (over HTTP) or 0 (false).
See also the LWP::Online manpage.
my $res = $ua->mirror( $url, $filename );
This method will get the document identified by URL and store it in
file called $filename. If the file already exists, then the request
will contain an If-Modified-Since header matching the modification
time of the file. If the document on the server has not changed since
this time, then nothing happens. If the document has been updated, it
will be downloaded again. The modification time of the file will be
forced to match that of the server.
The return value is an the HTTP::Response manpage object.
my $res = $ua->post( $url, \%form );
my $res = $ua->post( $url, \@form );
my $res = $ua->post( $url, \%form, $field_name => $value, ... );
my $res = $ua->post( $url, $field_name => $value, Content => \%form );
my $res = $ua->post( $url, $field_name => $value, Content => \@form );
my $res = $ua->post( $url, $field_name => $value, Content => $content );
This method will dispatch a POST request on the given URL, with
%form or @form providing the key/value pairs for the fill-in form
content. Additional headers and content options are the same as for
the get in the LWP::UserAgent manpage method.
This method will use the POST function from the HTTP::Request::Common manpage
to build the request. See the HTTP::Request::Common manpage for a details on
how to pass form content and other advanced features.
# Any version of HTTP::Message works with this form:
my $res = $ua->put( $url, $field_name => $value, Content => $content );
# Using hash or array references requires HTTP::Message >= 6.07
use HTTP::Request 6.07;
my $res = $ua->put( $url, \%form );
my $res = $ua->put( $url, \@form );
my $res = $ua->put( $url, \%form, $field_name => $value, ... );
my $res = $ua->put( $url, $field_name => $value, Content => \%form );
my $res = $ua->put( $url, $field_name => $value, Content => \@form );
This method will dispatch a PUT request on the given URL, with
%form or @form providing the key/value pairs for the fill-in form
content. Additional headers and content options are the same as for
the get in the LWP::UserAgent manpage method.
CAVEAT:
This method can only accept content that is in key-value pairs when using
the HTTP::Request::Common manpage prior to version 6.07. Any use of hash or array
references will result in an error prior to version 6.07.
This method will use the PUT function from the HTTP::Request::Common manpage
to build the request. See the HTTP::Request::Common manpage for a details on
how to pass form content and other advanced features.
my $res = $ua->request( $request );
my $res = $ua->request( $request, $content_file );
my $res = $ua->request( $request, $content_cb );
my $res = $ua->request( $request, $content_cb, $read_size_hint );
This method will dispatch the given $request object. Normally this
will be an instance of the the HTTP::Request manpage class, but any object with
a similar interface will do. The return value is an the HTTP::Response manpage object.
The request method will process redirects and authentication
responses transparently. This means that it may actually send several
simple requests via the simple_request in the LWP::UserAgent manpage method described below.
The request methods described above; get in the LWP::UserAgent manpage, head in the LWP::UserAgent manpage, post in the LWP::UserAgent manpage and mirror in the LWP::UserAgent manpage will all dispatch the request they build via this method. They are convenience methods that simply hide the creation of the request object for you.
The $content_file, $content_cb and $read_size_hint all correspond to
options described with the get in the LWP::UserAgent manpage method above. Note that errors
writing to the content file (for example due to permission denied
or the filesystem being full) will be reported via the Client-Aborted
or X-Died response headers, and not the is_success method.
You are allowed to use a CODE reference as content in the request
object passed in. The content function should return the content
when called. The content can be returned in chunks. The content
function will be invoked repeatedly until it return an empty string to
signal that there is no more content.
my $request = HTTP::Request->new( ... );
my $res = $ua->simple_request( $request );
my $res = $ua->simple_request( $request, $content_file );
my $res = $ua->simple_request( $request, $content_cb );
my $res = $ua->simple_request( $request, $content_cb, $read_size_hint );
This method dispatches a single request and returns the response received. Arguments are the same as for the request in the LWP::UserAgent manpage described above.
The difference from request in the LWP::UserAgent manpage is that simple_request will not try to
handle redirects or authentication responses. The request in the LWP::UserAgent manpage method
will, in fact, invoke this method for each simple request it sends.
The following methods will be invoked as requests are processed. These methods are documented here because subclasses of the LWP::UserAgent manpage might want to override their behaviour.
# This checks wantarray and can either return an array:
my ($user, $pass) = $ua->get_basic_credentials( $realm, $uri, $isproxy );
# or a string that looks like "user:pass"
my $creds = $ua->get_basic_credentials($realm, $uri, $isproxy);
This is called by request in the LWP::UserAgent manpage to retrieve credentials for documents
protected by Basic or Digest Authentication. The arguments passed in
is the $realm provided by the server, the $uri requested and a
boolean flag to indicate if this is authentication against a proxy server.
The method should return a username and password. It should return an
empty list to abort the authentication resolution attempt. Subclasses
can override this method to prompt the user for the information. An
example of this can be found in lwp-request program distributed
with this library.
The base implementation simply checks a set of pre-stored member variables, set up with the credentials in the LWP::UserAgent manpage method.
$request = $ua->prepare_request( $request );
This method is invoked by simple_request in the LWP::UserAgent manpage. Its task is
to modify the given $request object by setting up various headers based
on the attributes of the user agent. The return value should normally be the
$request object passed in. If a different request object is returned
it will be the one actually processed.
The headers affected by the base implementation are; User-Agent,
From, Range and Cookie.
my $prog = $ua->progress( $status, $request_or_response );
This is called frequently as the response is received regardless of
how the content is processed. The method is called with $status
``begin'' at the start of processing the request and with $state ``end''
before the request method returns. In between these $status will be
the fraction of the response currently received or the string ``tick''
if the fraction can't be calculated.
When $status is ``begin'' the second argument is the the HTTP::Request manpage object,
otherwise it is the the HTTP::Response manpage object.
my $bool = $ua->redirect_ok( $prospective_request, $response );
This method is called by request in the LWP::UserAgent manpage before it tries to follow a
redirection to the request in $response. This should return a true
value if this redirection is permissible. The $prospective_request
will be the request to be sent if this method returns true.
The base implementation will return false unless the method
is in the object's requests_redirectable list,
false if the proposed redirection is to a file://...
URL, and true otherwise.
See the LWP manpage for a complete overview of libwww-perl5. See the lwpcook manpage and the scripts lwp-request and lwp-download for examples of usage.
See the HTTP::Request manpage and the HTTP::Response manpage for a description of the message objects dispatched and received. See the HTTP::Request::Common manpage and the HTML::Form manpage for other ways to build request objects.
See the WWW::Mechanize manpage and the WWW::Search manpage for examples of more specialized user agents based on the LWP::UserAgent manpage.
Copyright 1995-2009 Gisle Aas.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
| LWP::UserAgent - Web user agent class |