… | |
… | |
263 | In even rarer cases you want total control over how AnyEvent::HTTP |
263 | In even rarer cases you want total control over how AnyEvent::HTTP |
264 | establishes connections. Normally it uses L<AnyEvent::Socket::tcp_connect> |
264 | establishes connections. Normally it uses L<AnyEvent::Socket::tcp_connect> |
265 | to do this, but you can provide your own C<tcp_connect> function - |
265 | to do this, but you can provide your own C<tcp_connect> function - |
266 | obviously, it has to follow the same calling conventions, except that it |
266 | obviously, it has to follow the same calling conventions, except that it |
267 | may always return a connection guard object. |
267 | may always return a connection guard object. |
|
|
268 | |
|
|
269 | The connections made by this hook will be treated as equivalent to |
|
|
270 | connecitons made the built-in way, specifically, they will be put into |
|
|
271 | and taken from the persistent conneciton cache. If your C<$tcp_connect> |
|
|
272 | function is incompatible with this kind of re-use, consider switching off |
|
|
273 | C<persistent> connections and/or providing a C<session> identifier. |
268 | |
274 | |
269 | There are probably lots of weird uses for this function, starting from |
275 | There are probably lots of weird uses for this function, starting from |
270 | tracing the hosts C<http_request> actually tries to connect, to (inexact |
276 | tracing the hosts C<http_request> actually tries to connect, to (inexact |
271 | but fast) host => IP address caching or even socks protocol support. |
277 | but fast) host => IP address caching or even socks protocol support. |
272 | |
278 | |