AnyEvent-HTTP
view release on metacpan or search on metacpan
NAME
AnyEvent::HTTP - simple but non-blocking HTTP/HTTPS client
SYNOPSIS
use AnyEvent::HTTP;
http_get "http://www.nethype.de/", sub { print $_[1] };
# ... do something else here
DESCRIPTION
This module is an AnyEvent user, you need to make sure that you use and
run a supported event loop.
This module implements a simple, stateless and non-blocking HTTP client.
It supports GET, POST and other request methods, cookies and more, all
on a very low level. It can follow redirects, supports proxies, and
automatically limits the number of connections to the values specified
in the RFC.
It should generally be a "good client" that is enough for most HTTP
tasks. Simple tasks should be simple, but complex tasks should still be
possible as the user retains control over request and response headers.
The caller is responsible for authentication management, cookies (if the
simplistic implementation in this module doesn't suffice), referer and
other high-level protocol details for which this module offers only
limited support.
METHODS
http_get $url, key => value..., $cb->($data, $headers)
Executes an HTTP-GET request. See the http_request function for
details on additional parameters and the return value.
http_head $url, key => value..., $cb->($data, $headers)
Executes an HTTP-HEAD request. See the http_request function for
details on additional parameters and the return value.
http_post $url, $body, key => value..., $cb->($data, $headers)
Executes an HTTP-POST request with a request body of $body. See the
http_request function for details on additional parameters and the
return value.
http_request $method => $url, key => value..., $cb->($data, $headers)
Executes a HTTP request of type $method (e.g. "GET", "POST"). The
URL must be an absolute http or https URL.
When called in void context, nothing is returned. In other contexts,
"http_request" returns a "cancellation guard" - you have to keep the
object at least alive until the callback get called. If the object
gets destroyed before the callback is called, the request will be
cancelled.
The callback will be called with the response body data as first
argument (or "undef" if an error occurred), and a hash-ref with
response headers (and trailers) as second argument.
All the headers in that hash are lowercased. In addition to the
response headers, the "pseudo-headers" (uppercase to avoid clashing
with possible response headers) "HTTPVersion", "Status" and "Reason"
contain the three parts of the HTTP Status-Line of the same name. If
an error occurs during the body phase of a request, then the
original "Status" and "Reason" values from the header are available
as "OrigStatus" and "OrigReason".
The pseudo-header "URL" contains the actual URL (which can differ
from the requested URL when following redirects - for example, you
might get an error that your URL scheme is not supported even though
your URL is a valid http URL because it redirected to an ftp URL, in
which case you can look at the URL pseudo header).
The pseudo-header "Redirect" only exists when the request was a
result of an internal redirect. In that case it is an array
reference with the "($data, $headers)" from the redirect response.
Note that this response could in turn be the result of a redirect
itself, and "$headers->{Redirect}[1]{Redirect}" will then contain
the original response, and so on.
If the server sends a header multiple times, then their contents
will be joined together with a comma (","), as per the HTTP spec.
If an internal error occurs, such as not being able to resolve a
hostname, then $data will be "undef", "$headers->{Status}" will be
590-599 and the "Reason" pseudo-header will contain an error
message. Currently the following status codes are used:
595 - errors during connection establishment, proxy handshake.
596 - errors during TLS negotiation, request sending and header
processing.
597 - errors during body receiving or processing.
598 - user aborted request via "on_header" or "on_body".
599 - other, usually nonretryable, errors (garbled URL etc.).
A typical callback might look like this:
sub {
my ($body, $hdr) = @_;
if ($hdr->{Status} =~ /^2/) {
... everything should be ok
} else {
print "error, $hdr->{Status} $hdr->{Reason}\n";
}
}
Additional parameters are key-value pairs, and are fully optional.
They include:
recurse => $count (default: $MAX_RECURSE)
Whether to recurse requests or not, e.g. on redirects,
code of 598).
The downside to cancelling the request is that it makes it
impossible to re-use the connection.
This callback is useful when the data is too large to be held in
memory (so the callback writes it to a file) or when only some
information should be extracted, or when the body should be
processed incrementally.
It is usually preferred over doing your own body handling via
"want_body_handle", but in case of streaming APIs, where HTTP is
only used to create a connection, "want_body_handle" is the
better alternative, as it allows you to install your own event
handler, reducing resource usage.
want_body_handle => $enable
When enabled (default is disabled), the behaviour of
AnyEvent::HTTP changes considerably: after parsing the headers,
and instead of downloading the body (if any), the completion
callback will be called. Instead of the $body argument
containing the body data, the callback will receive the
AnyEvent::Handle object associated with the connection. In error
cases, "undef" will be passed. When there is no body (e.g.
status 304), the empty string will be passed.
The handle object might or might not be in TLS mode, might be
connected to a proxy, be a persistent connection, use chunked
transfer encoding etc., and configured in unspecified ways. The
user is responsible for this handle (it will not be used by this
module anymore).
This is useful with some push-type services, where, after the
initial headers, an interactive protocol is used (typical
example would be the push-style twitter API which starts a
JSON/XML stream).
If you think you need this, first have a look at "on_body", to
see if that doesn't solve your problem in a better way.
persistent => $boolean
Try to create/reuse a persistent connection. When this flag is
set (default: true for idempotent requests, false for all
others), then "http_request" tries to re-use an existing
(previously-created) persistent connection to same host (i.e.
identical URL scheme, hostname, port and sessionid) and, failing
that, tries to create a new one.
Requests failing in certain ways will be automatically retried
once, which is dangerous for non-idempotent requests, which is
why it defaults to off for them. The reason for this is because
the bozos who designed HTTP/1.1 made it impossible to
distinguish between a fatal error and a normal connection
timeout, so you never know whether there was a problem with your
request or not.
When reusing an existent connection, many parameters (such as
TLS context) will be ignored. See the "sessionid" parameter for
a workaround.
keepalive => $boolean
Only used when "persistent" is also true. This parameter decides
whether "http_request" tries to handshake a HTTP/1.0-style
keep-alive connection (as opposed to only a HTTP/1.1 persistent
connection).
The default is true, except when using a proxy, in which case it
defaults to false, as HTTP/1.0 proxies cannot support this in a
meaningful way.
handle_params => { key => value ... }
The key-value pairs in this hash will be passed to any
AnyEvent::Handle constructor that is called - not all requests
will create a handle, and sometimes more than one is created, so
this parameter is only good for setting hints.
Example: set the maximum read size to 4096, to potentially
conserve memory at the cost of speed.
handle_params => {
max_read_size => 4096,
},
Example: do a simple HTTP GET request for http://www.nethype.de/ and
print the response body.
http_request GET => "http://www.nethype.de/", sub {
my ($body, $hdr) = @_;
print "$body\n";
};
Example: do a HTTP HEAD request on https://www.google.com/, use a
timeout of 30 seconds.
http_request
HEAD => "https://www.google.com",
headers => { "user-agent" => "MySearchClient 1.0" },
timeout => 30,
sub {
my ($body, $hdr) = @_;
use Data::Dumper;
print Dumper $hdr;
}
;
Example: do another simple HTTP GET request, but immediately try to
cancel it.
my $request = http_request GET => "http://www.nethype.de/", sub {
my ($body, $hdr) = @_;
print "$body\n";
};
undef $request;
DNS CACHING
AnyEvent::HTTP uses the AnyEvent::Socket::tcp_connect function for the
actual connection, which in turn uses AnyEvent::DNS to resolve
hostnames. The latter is a simple stub resolver and does no caching on
its own. If you want DNS caching, you currently have to provide your own
default resolver (by storing a suitable resolver object in
$AnyEvent::DNS::RESOLVER) or your own "tcp_connect" callback.
GLOBAL FUNCTIONS AND VARIABLES
( run in 0.401 second using v1.01-cache-2.11-cpan-df04353d9ac )