AnyEvent-HTTP
view release on metacpan or search on metacpan
=item tcp_connect => $callback->($host, $service, $connect_cb, $prepare_cb)
In even rarer cases you want total control over how AnyEvent::HTTP
establishes connections. Normally it uses L<AnyEvent::Socket::tcp_connect>
to do this, but you can provide your own C<tcp_connect> function -
obviously, it has to follow the same calling conventions, except that it
may always return a connection guard object.
The connections made by this hook will be treated as equivalent to
connections made the built-in way, specifically, they will be put into
and taken from the persistent connection cache. If your C<$tcp_connect>
function is incompatible with this kind of re-use, consider switching off
C<persistent> connections and/or providing a C<sessionid> identifier.
There are probably lots of weird uses for this function, starting from
tracing the hosts C<http_request> actually tries to connect, to (inexact
but fast) host => IP address caching or even socks protocol support.
=item on_header => $callback->($headers)
When specified, this callback will be called with the header hash as soon
as headers have been successfully received from the remote server (not on
locally-generated errors).
It has to return either true (in which case AnyEvent::HTTP will continue),
or false, in which case AnyEvent::HTTP will cancel the download (and call
the finish callback with an error code of C<598>).
This callback is useful, among other things, to quickly reject unwanted
content, which, if it is supposed to be rare, can be faster than first
doing a C<HEAD> request.
The downside is that cancelling the request makes it impossible to re-use
the connection. Also, the C<on_header> callback will not receive any
trailer (headers sent after the response body).
Example: cancel the request unless the content-type is "text/html".
on_header => sub {
$_[0]{"content-type"} =~ /^text\/html\s*(?:;|$)/
},
=item on_body => $callback->($partial_body, $headers)
When specified, all body data will be passed to this callback instead of
to the completion callback. The completion callback will get the empty
string instead of the body data.
It has to return either true (in which case AnyEvent::HTTP will continue),
or false, in which case AnyEvent::HTTP will cancel the download (and call
the completion callback with an error code of C<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
C<want_body_handle>, but in case of streaming APIs, where HTTP is
only used to create a connection, C<want_body_handle> is the better
alternative, as it allows you to install your own event handler, reducing
resource usage.
=item 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 C<$body> argument containing the body data, the
callback will receive the L<AnyEvent::Handle> object associated with the
connection. In error cases, C<undef> will be passed. When there is no body
(e.g. status C<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 C<on_body>, to see if
that doesn't solve your problem in a better way.
=item persistent => $boolean
Try to create/reuse a persistent connection. When this flag is set
(default: true for idempotent requests, false for all others), then
C<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 C<sessionid> parameter for a workaround.
=item keepalive => $boolean
Only used when C<persistent> is also true. This parameter decides whether
C<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.
=item handle_params => { key => value ... }
The key-value pairs in this hash will be passed to any L<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.
( run in 1.713 second using v1.01-cache-2.11-cpan-140bd7fdf52 )