LWP::UserAgent - Web user agent class
require LWP::UserAgent;
my $ua = LWP::UserAgent->new; $ua->timeout(10); $ua->env_proxy;
my $response = $ua->get('http://search.cpan.org/');
if ($response->is_success) { print $response->content; # or whatever } else { die $response->status_line; }
In normal use the application creates an "LWP::UserAgent" object, and then configures it with values for timeouts, proxies, name, etc. It then creates an instance of "HTTP::Request" 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 "HTTP::Response" object. There are convenience methods for sending the most common request types: get(), head() and post(). When using these methods then 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 "HTTP::Request" objects and receive "HTTP::Response" 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.
KEY DEFAULT ----------- -------------------- agent "libwww-perl/#.##" from undef conn_cache undef cookie_jar undef default_headers HTTP::Headers->new max_size undef max_redirect 7 parse_head 1 protocols_allowed undef protocols_forbidden undef requests_redirectable ['GET', 'HEAD'] timeout 180
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() method below). If the "keep_alive" option is passed in, then a "LWP::ConnCache" is set up (see conn_cache() method below). The "keep_alive" value is passed on as the "total_capacity" for the connection cache.
The following attributes 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.
If the $product_id ends with space then the _agent() 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. Examples are:
$ua->agent('Checkbot/0.4 ' . $ua->_agent); $ua->agent('Checkbot/0.4 '); # same as above $ua->agent('Mozilla/5.0'); $ua->agent(""); # don't identify
$ua->from('gaas@cpan.org');
The default is to not send a ``From'' header. See the default_headers() method for the more general interface that allow any header to be defaulted.
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 as the $cookie_jar_object, then it is replaced with an instance of "HTTP::Cookies" that is initialized based on the hash. This form also automatically loads the "HTTP::Cookies" 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"));
$ua->default_headers->push_header('Accept-Language' => "no, en");
$ua->default_header('Accept-Language' => "no, en");
By default, the value is 7. This means that if you call request() method 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.
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.
To delete the list, call: "$ua->protocols_allowed(undef)"
By default, an object has neither a "protocols_allowed" list, nor a "protocols_forbidden" list.
Note that having a "protocols_allowed" list causes any "protocols_forbidden" list to be ignored.
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.
To delete the list, call: "$ua->protocols_forbidden(undef)"
push @{ $ua->requests_redirectable }, 'POST';
The requests 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() method to actually return might be longer.
$ua->proxy(['http', 'ftp'], 'http://proxy.sn.no:8001/'); $ua->proxy('gopher', 'http://proxy.sn.no:8001/');
The first form specifies that the URL is to be used for proxying of 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.
$ua->no_proxy('localhost', 'no', ...);
gopher_proxy=http://proxy.my.place/ wais_proxy=http://proxy.my.place/ no_proxy="localhost,my.domain" 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.
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.
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.
This method will use the POST() function from "HTTP::Request::Common" to build the request. See HTTP::Request::Common for a details on how to pass form content and other advanced features.
The return value is the the response 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() method described below.
The request methods described above; get(), head(), post() and mirror(), will all dispatch the request they build via this method. They are convenience methods that simply hides 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() method above.
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.
The difference from request() is that simple_request() will not try to handle redirects or authentication responses. The request() method will in fact invoke this method for each simple request it sends.
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.
The headers affected by the base implementation are; ``User-Agent'', ``From'', ``Range'' and ``Cookie''.
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.
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() method.
See HTTP::Request and HTTP::Response for a description of the message objects dispatched and received. See HTTP::Request::Common and HTML::Form for other ways to build request objects.
See WWW::Mechanize and WWW::Search for examples of more specialized user agents based on "LWP::UserAgent".
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |