595 - errors during connection etsbalishment, 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.).

   sub {
      my ($body, $hdr) = @_;
      if ($hdr->{Status} =~ /^2/) {
         ... everything should be ok
      } else {
         print "error, $hdr->{Status} $hdr->{Reason}\n";
      }
   }

recurse => $count (default: $MAX_RECURSE)

Whether to recurse requests or not, e.g. on redirects, authentication retries and so on, and how often to do so.

headers => hashref

The request headers to use. Currently, "http_request" may provide its own "Host:", "Content-Length:", "Connection:" and "Cookie:" headers and will provide defaults at least for "TE:", "Referer:" and "User-Agent:" (this can be suppressed by using "undef" for these headers in which case they won't be sent at all).

 

You really should provide your own "User-Agent:" header value that is appropriate for your program - I wouldn't be surprised if the default AnyEvent string gets blocked by webservers sooner or later.

 

Also, make sure that your headers names and values do not contain any embedded newlines.

timeout => $seconds

The time-out to use for various stages - each connect attempt will reset the timeout, as will read or write activity, i.e. this is not an overall timeout.

 

Default timeout is 5 minutes.

proxy => [$host, $port[, $scheme]] or undef

Use the given http proxy for all requests, or no proxy if "undef" is used.

 

$scheme must be either missing or must be "http" for HTTP.

 

If not specified, then the default proxy is used (see "AnyEvent::HTTP::set_proxy").

body => $string

The request body, usually empty. Will be sent as-is (future versions of this module might offer more options).

cookie_jar => $hash_ref

Passing this parameter enables (simplified) cookie-processing, loosely based on the original netscape specification.

 

The $hash_ref must be an (initially empty) hash reference which will get updated automatically. It is possible to save the cookie jar to persistent storage with something like JSON or Storable - see the "AnyEvent::HTTP::cookie_jar_expire" function if you wish to remove expired or session-only cookies, and also for documentation on the format of the cookie jar.

 

Note that this cookie implementation is not meant to be complete. If you want complete cookie management you have to do that on your own. "cookie_jar" is meant as a quick fix to get most cookie-using sites working. Cookies are a privacy disaster, do not use them unless required to.

 

When cookie processing is enabled, the "Cookie:" and "Set-Cookie:" headers will be set and handled by this module, otherwise they will be left untouched.

tls_ctx => $scheme | $tls_ctx

Specifies the AnyEvent::TLS context to be used for https connections. This parameter follows the same rules as the "tls_ctx" parameter to AnyEvent::Handle, but additionally, the two strings "low" or "high" can be specified, which give you a predefined low-security (no verification, highest compatibility) and high-security (CA and common-name verification) TLS context.

 

The default for this option is "low", which could be interpreted as "give me the page, no matter what".

 

See also the "sessionid" parameter.

session => $string

The module might reuse connections to the same host internally. Sometimes (e.g. when using TLS), you do not want to reuse connections from other sessions. This can be achieved by setting this parameter to some unique ID (such as the address of an object storing your state data, or the TLS context) - only connections using the same unique ID will be reused.

on_prepare => $callback->($fh)

In rare cases you need to "tune" the socket before it is used to connect (for exmaple, to bind it on a given IP address). This parameter overrides the prepare callback passed to "AnyEvent::Socket::tcp_connect" and behaves exactly the same way (e.g. it has to provide a timeout). See the description for the $prepare_cb argument of "AnyEvent::Socket::tcp_connect" for details.

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 AnyEvent::Socket::tcp_connect to do this, but you can provide your own "tcp_connect" function - obviously, it has to follow the same calling conventions, except that it may always return a connection guard object.

 

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 the host 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 "session" 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,
   },
    

   http_request GET => "http://www.nethype.de/", sub {
      my ($body, $hdr) = @_;
      print "$body\n";
   };

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

   my $request = http_request GET => "http://www.nethype.de/", sub {
      my ($body, $hdr) = @_;
      print "$body\n";
   };
   undef $request;