view release on metacpan or  search on metacpan

README  view on Meta::CPAN

            your own "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
            $tcp_connect function is incompatible with this kind of re-use,
            consider switching off "persistent" connections and/or providing
            a "sessionid" identifier.

            There are probably lots of weird uses for this function,
            starting from tracing the hosts "http_request" actually tries to
            connect, to (inexact but fast) host => IP address caching or
            even socks protocol support.

        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
            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 "HEAD" request.

            The downside is that cancelling the request makes it impossible
            to re-use the connection. Also, the "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*(?:;|$)/
               },

        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 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