|
NAMEHTTP::Proxy - A pure Perl HTTP proxySYNOPSISuse HTTP::Proxy; # initialisation my $proxy = HTTP::Proxy->new( port => 3128 ); # alternate initialisation my $proxy = HTTP::Proxy->new; $proxy->port( 3128 ); # the classical accessors are here! # this is a MainLoop-like method $proxy->start; DESCRIPTIONThis module implements an HTTP proxy, using an HTTP::Daemon to accept client connections, and an LWP::UserAgent to ask for the requested pages.The most interesting feature of this proxy object is its ability to filter the HTTP requests and responses through user-defined filters. Once the proxy is created, with the "new()" method, it is possible to alter its behaviour by adding so-called "filters." This is done by the "push_filter()" method. Once the filter is ready to run, it can be launched, with the "start()" method. This method does not normally return until the proxy is killed or otherwise stopped. An important thing to note is that the proxy is (except when running the "NoFork" engine) a forking proxy: it doesn't support passing information between child processes, and you can count on reliable information passing only during a single HTTP connection (request + response). FILTERSYou can alter the way the default HTTP::Proxy works by plugging callbacks (filter objects, actually) at different stages of the request/response handling.When a request is received by the HTTP::Proxy object, it is filtered through a standard filter that transforms the request according to RFC 2616 (by adding the "Via:" header, and other transformations). This is the default, bare minimum behaviour. The response is also filtered in the same manner. There is a total of four filter chains: "request-headers", "request-body", "response-headers" and "response-body". You can add your own filters to the default ones with the "push_filter()" method. The method pushes a filter on the appropriate filter stack. $proxy->push_filter( response => $filter ); The headers/body category is determined by the base class of the filter. There are two base classes for filters, which are HTTP::Proxy::HeaderFilter and HTTP::Proxy::BodyFilter (the names are self-explanatory). See the documentation of those two classes to find out how to write your own header and body filters. The named parameter is used to determine the request/response part. It is possible to push the same filter on the request and response stacks, as in the following example: $proxy->push_filter( request => $filter, response => $filter ); If several filters match the message, they will be applied in the order they were pushed on their filter stack. Named parameters can be used to create the match routine. They are: method - the request method scheme - the URI scheme host - the URI authority (host:port) path - the URI path query - the URI query string mime - the MIME type (for a response-body filter) The filters are applied only when all the the parameters match the request or the response. All these named parameters have default values, which are: method => 'OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT' scheme => 'http' host => '' path => '' query => '' mime => 'text/*' The "mime" parameter is a glob-like string, with a required "/" character and a "*" as a wildcard. Thus, "*/*" matches all responses, and "" those with no "Content-Type:" header. To match any repines (with or without a "Content-Type:" header), use "undef". The "mime" parameter is only meaningful with the "response-body" filter stack. It is ignored if passed to any other filter stack. The "method" and "scheme" parameters are strings consisting of comma-separated values. The "host" and "path" parameters are regular expressions. A match routine is compiled by the proxy and used to check if a particular request or response must be filtered through a particular filter. It is also possible to push several filters on the same stack with the same match subroutine: # convert italics to bold $proxy->push_filter( mime => 'text/html', response => HTTP::Proxy::BodyFilter::tags->new(), response => HTTP::Proxy::BodyFilter::simple->new( sub { ${ $_[1] } =~ s!(</?)i>!$1b>!ig } ) ); For more details regarding the creation of new filters, check the HTTP::Proxy::HeaderFilter and HTTP::Proxy::BodyFilter documentation. Here's an example of subclassing a base filter class: # fixes a common typo ;-) # but chances are that this will modify a correct URL { package FilterPerl; use base qw( HTTP::Proxy::BodyFilter ); sub filter { my ( $self, $dataref, $message, $protocol, $buffer ) = @_; $$dataref =~ s/PERL/Perl/g; } } $proxy->push_filter( response => FilterPerl->new() ); Other examples can be found in the documentation for HTTP::Proxy::HeaderFilter, HTTP::Proxy::BodyFilter, HTTP::Proxy::HeaderFilter::simple, HTTP::Proxy::BodyFilter::simple. # a simple anonymiser # see eg/anonymiser.pl for the complete code $proxy->push_filter( mime => undef, request => HTTP::Proxy::HeaderFilter::simple->new( sub { $_[1]->remove_header(qw( User-Agent From Referer Cookie )) }, ), response => HTTP::Proxy::HeaderFilter::simple->new( sub { $_[1]->remove_header(qw( Set-Cookie )); }, ) ); IMPORTANT: If you use your own LWP::UserAgent, you must install it before your calls to "push_filter()", otherwise the match method will make wrong assumptions about the schemes your agent supports. NOTE: It is likely that possibility of changing the agent or the daemon may disappear in future versions. METHODSConstructor and initialisation
Accessors and mutatorsHTTP::Proxy class has several accessors and mutators.Called with arguments, the accessor returns the current value. Called with a single argument, it sets the current value and returns the previous one, in case you want to keep it. If you call a read-only accessor with a parameter, this parameter will be ignored. The defined accessors are (in alphabetical order):
Connection handling methods
Other methods
Apache-like attributesHTTP::Proxy has several Apache-like attributes that control the way the HTTP and TCP connections are handled.The following attributes control the TCP connection. They are passed to the underlying HTTP::Proxy::Engine, which may (or may not) use them to change its behaviour.
Those attributes control the HTTP connection:
EXPORTED SYMBOLSNo symbols are exported by default. The ":log" tag exports all the logging constants.BUGSThis module does not work under Windows, but I can't see why, and do not have a development platform under that system. Patches and explanations very welcome.I guess it is because "fork()" is not well supported. $proxy->maxchild(0);
Several people have tried to help, but we haven't found a way to make it work correctly yet. As from version 0.16, the default engine is HTTP::Proxy::Engine::NoFork. Let me know if it works better. SEE ALSOHTTP::Proxy::Engine, HTTP::Proxy::BodyFilter, HTTP::Proxy::HeaderFilter, the examples in eg/.AUTHORPhilippe "BooK" Bruhat, <book@cpan.org>.There is also a mailing-list: http-proxy@mongueurs.net for general discussion about HTTP::Proxy. THANKSMany people helped me during the development of this module, either on mailing-lists, IRC or over a beer in a pub...So, in no particular order, thanks to the libwww-perl team for such a terrific suite of modules, perl-qa (tips for testing), the French Perl Mongueurs (for code tricks, beers and encouragements) and my growing user base... ";-)" I'd like to particularly thank Dan Grigsby, who's been using HTTP::Proxy since 2003 (before the filter classes even existed). He is apparently making a living from a product based on HTTP::Proxy. Thanks a lot for your confidence in my work! COPYRIGHTCopyright 2002-2015, Philippe Bruhat.LICENSEThis module is free software; you can redistribute it or modify it under the same terms as Perl itself.
Visit the GSP FreeBSD Man Page Interface. |