POE-Component-Client-HTTP
view release on metacpan or search on metacpan
maintainer may be reached. It defaults to undef, which means no From
header will be included in requests.
MaxSize => OCTETS
"MaxSize" specifies the largest response to accept from a server. The
content of larger responses will be truncated to OCTET octets. This
has been used to return the <head></head> section of web pages without
the need to wade through <body></body>.
NoProxy => [ $host_1, $host_2, ..., $host_N ]
NoProxy => "host1,host2,hostN"
"NoProxy" specifies a list of server hosts that will not be proxied.
It is useful for local hosts and hosts that do not properly support
proxying. If NoProxy is not specified, a list will be taken from the
NO_PROXY environment variable.
NoProxy => [ "localhost", "127.0.0.1" ],
NoProxy => "localhost,127.0.0.1",
BindAddr => $local_ip
Specify "BindAddr" to bind all client sockets to a particular local
address. The value of BindAddr will be passed through
POE::Component::Client::Keepalive to POE::Wheel::SocketFactory (as
"bind_address"). See that module's documentation for implementation
details.
BindAddr => "12.34.56.78"
Protocol => $http_protocol_string
"Protocol" advertises the protocol that the client wishes to see.
Under normal circumstances, it should be left to its default value:
"HTTP/1.1".
Proxy => [ $proxy_host, $proxy_port ]
Proxy => $proxy_url
Proxy => $proxy_url,$proxy_url,...
"Proxy" specifies one or more proxy hosts that requests will be passed
through. If not specified, proxy servers will be taken from the
HTTP_PROXY (or http_proxy) environment variable. No proxying will
occur unless Proxy is set or one of the environment variables exists.
The proxy can be specified either as a host and port, or as one or
more URLs. Proxy URLs must specify the proxy port, even if it is 80.
Proxy => [ "127.0.0.1", 80 ],
Proxy => "http://127.0.0.1:80/",
"Proxy" may specify multiple proxies separated by commas.
PoCo::Client::HTTP will choose proxies from this list at random. This
is useful for load balancing requests through multiple gateways.
Proxy => "http://127.0.0.1:80/,http://127.0.0.1:81/",
Streaming => OCTETS
"Streaming" changes allows Client::HTTP to return large content in
chunks (of OCTETS octets each) rather than combine the entire content
into a single HTTP::Response object.
By default, Client::HTTP reads the entire content for a response into
memory before returning an HTTP::Response object. This is obviously
bad for applications like streaming MP3 clients, because they often
fetch songs that never end. Yes, they go on and on, my friend.
When "Streaming" is set to nonzero, however, the response handler
receives chunks of up to OCTETS octets apiece. The response handler
accepts slightly different parameters in this case. ARG0 is also an
HTTP::Response object but it does not contain response content, and
ARG1 contains a a chunk of raw response content, or undef if the
stream has ended.
sub streaming_response_handler {
my $response_packet = $_[ARG1];
my ($response, $data) = @$response_packet;
print SAVED_STREAM $data if defined $data;
}
FollowRedirects => $number_of_hops_to_follow
"FollowRedirects" specifies how many redirects (e.g. 302 Moved) to
follow. If not specified defaults to 0, and thus no redirection is
followed. This maintains compatibility with the previous behavior,
which was not to follow redirects at all.
If redirects are followed, a response chain should be built, and can
be accessed through $response_object->previous(). See HTTP::Response
for details here.
Timeout => $query_timeout
"Timeout" sets how long POE::Component::Client::HTTP has to process an
application's request, in seconds. "Timeout" defaults to 180 (three
minutes) if not specified.
It's important to note that the timeout begins when the component
receives an application's request, not when it attempts to connect to
the web server.
Timeouts may result from sending the component too many requests at
once. Each request would need to be received and tracked in order.
Consider this:
$_[KERNEL]->post(component => request => ...) for (1..15_000);
15,000 requests are queued together in one enormous bolus. The
component would receive and initialize them in order. The first socket
activity wouldn't arrive until the 15,000th request was set up. If
that took longer than "Timeout", then the requests that have waited
too long would fail.
"ConnectionManager"'s own timeout and concurrency limits also affect
how many requests may be processed at once. For example, most of the
15,000 requests would wait in the connection manager's pool until
sockets become available. Meanwhile, the "Timeout" would be counting
down.
Applications may elect to control concurrency outside the component's
"Timeout". They may do so in a few ways.
The easiest way is to limit the initial number of requests to
something more manageable. As responses arrive, the application should
handle them and start new requests. This limits concurrency to the
initial request count.
An application may also outsource job throttling to another module,
such as POE::Component::JobQueue.
In any case, "Timeout" and "ConnectionManager" may be tuned to
maximize timeouts and concurrency limits. This may help in some cases.
Developers should be aware that doing so will increase memory usage.
POE::Component::Client::HTTP and KeepAlive track requests in memory,
while applications are free to keep pending requests on disk.
ACCEPTED EVENTS
Sessions communicate asynchronously with PoCo::Client::HTTP. They post
requests to it, and it posts responses back.
request
Requests are posted to the component's "request" state. They include an
HTTP::Request object which defines the request. For example:
$kernel->post(
'ua', 'request', # http session alias & state
'response', # my state to receive responses
GET('http://poe.perl.org'), # a simple HTTP request
'unique id', # a tag to identify the request
'progress', # an event to indicate progress
'http://1.2.3.4:80/' # proxy to use for this request
);
Requests include the state to which responses will be posted. In the
previous example, the handler for a 'response' state will be called with
each HTTP response. The "progress" handler is optional and if installed,
the component will provide progress metrics (see sample handler below).
The "proxy" parameter is optional and if not defined, a default proxy
will be used if configured. No proxy will be used if neither a default
one nor a "proxy" parameter is defined.
pending_requests_count
There's also a pending_requests_count state that returns the number of
requests currently being processed. To receive the return value, it must
be invoked with $kernel->call().
my $count = $kernel->call('ua' => 'pending_requests_count');
NOTE: Sometimes the count might not be what you expected, because
responses are currently in POE's queue and you haven't processed them.
This could happen if you configure the "ConnectionManager"'s concurrency
to a high enough value.
cancel
Cancel a specific HTTP request. Requires a reference to the original
request (blessed or stringified) so it knows which one to cancel. See
"progress handler" below for notes on canceling streaming requests.
To cancel a request based on its blessed HTTP::Request object:
$kernel->post( component => cancel => $http_request );
To cancel a request based on its stringified HTTP::Request object:
$kernel->post( component => cancel => "$http_request" );
shutdown
Responds to all pending requests with 408 (request timeout), and then
shuts down the component and all subcomponents.
SENT EVENTS
response handler
In addition to all the usual POE parameters, HTTP responses come with
two list references:
my ($request_packet, $response_packet) = @_[ARG0, ARG1];
$request_packet contains a reference to the original HTTP::Request
object. This is useful for matching responses back to the requests that
generated them.
my $http_request_object = $request_packet->[0];
my $http_request_tag = $request_packet->[1]; # from the 'request' post
$response_packet contains a reference to the resulting HTTP::Response
object.
my $http_response_object = $response_packet->[0];
Please see the HTTP::Request and HTTP::Response manpages for more
information.
progress handler
The example progress handler shows how to calculate a percentage of
download completion.
sub progress_handler {
my $gen_args = $_[ARG0]; # args passed to all calls
my $call_args = $_[ARG1]; # args specific to the call
my $req = $gen_args->[0]; # HTTP::Request object being serviced
my $tag = $gen_args->[1]; # Request ID tag from.
my $got = $call_args->[0]; # Number of bytes retrieved so far.
my $tot = $call_args->[1]; # Total bytes to be retrieved.
my $oct = $call_args->[2]; # Chunk of raw octets received this time.
my $percent = $got / $tot * 100;
printf(
"-- %.0f%% [%d/%d]: %s\n", $percent, $got, $tot, $req->uri()
);
# To cancel the request:
# $_[KERNEL]->post( component => cancel => $req );
}
DEPRECATION WARNING
( run in 0.674 second using v1.01-cache-2.11-cpan-39bf76dae61 )