perlbal::manual::webserver(3pm) [debian man page]

Perlbal::Manual::WebServer(3pm) 			User Contributed Perl Documentation			   Perlbal::Manual::WebServer(3pm)

NAME

       Perlbal::Manual::WebServer - Configuring Perlbal as a Web Server

   VERSION
       Perlbal 1.78.

   DESCRIPTION
       How to configure a Perlbal Web Server service.

   READ ME FIRST
       Please read Perlbal::Manual::Configuration first for a better explanation on how to configure Perlbal. This document will make much more
       sense after reading that.

   Configuring Perlbal as a Web Server
       By default, perlbal looks for a configuration file at /etc/perlbal/perlbal.conf.

       You can also point perlbal at a different configuration file with the -c flag.

	   $ perlbal -c /home/user/perlbal.conf

       Here's a very simple example where we configure a simple web server that serves an index file under /tmp

	   CREATE SERVICE perlbal_test
	       SET role 	  = web_server
	       SET listen	  = 0.0.0.0:80
	       SET docroot	  = /tmp
	   ENABLE perlbal_test

       The first line creates a service called "perlbal_test". The last line enables that service.

       The three parameters state - in order - that the service is a web server, that it listens on all addresses on port 80, and that its
       document root is "/tmp".

   Parameters
       You can set parameters via commands of either forms:

	   SET <service-name> <param> = <value>
	   SET <param> = <value>

       dirindexing = bool
	       Show directory indexes when an HTTP request is for a directory. Warning: this is not an async operation, so will slow down Perlbal
	       on heavily loaded sites.

	       Default if false.

       docroot = directory/root
	       Directory root for web server.

       enable_concatenate_get = bool
	       Enable Perlbal's multiple-files-in-one-request mode, where a client have use a comma-separated list of files to return, always in
	       text/plain.

	       Useful for web apps which have dozens/hundreds of tiny css/js files, and don't trust browsers/etc to do pipelining.

	       Decreases overall round-trip latency a bunch, but requires app to be modified to support it. See t/17-concat.t test for details.

	       Default is false.

       enable_md5 = bool
	       Enable verification of the Content-MD5 header in HTTP PUT requests.

	       Default is true.

       enable_delete = bool
	       Enable HTTP DELETE requests.

	       Default is false.

       enable_put = bool
	       Enable HTTP PUT requests.

	       Default is false.

       index_files = comma-separated list of filenames
	       Comma-separated list of filenames to load when a user visits a directory URL, listed in order of preference.

	       Default is index.html.

       max_put_size = size
	       The maximum content-length that will be accepted for a PUT request, if enable_put is on.

	       Default is 0, which means there is no limit.

       min_put_directory = int
	       If PUT requests are enabled, require this many levels of directories to already exist. If not, fail.

	       Default is 0.

       server_tokens = bool
	       Whether to provide a "Server" header.

	       Perlbal by default adds a header to all replies (such as the web_server role). By setting this default to "off", you can prevent
	       Perlbal from identifying itself.

	       Default is "on".

   SEE ALSO
       Perlbal::Manual::Configuration, Perlbal::Manual::Management.

perl v5.14.2							    2012-02-20					   Perlbal::Manual::WebServer(3pm)

Perlbal::Plugin::Cgilike(3pm)				User Contributed Perl Documentation			     Perlbal::Plugin::Cgilike(3pm)

NAME

       Perlbal::Plugin::Cgilike - Handle Perlbal requests with a Perl subroutine

DESCRIPTION

       This module allows responses to be handled with a simple API that's similar in principle to CGI, mod_perl response handlers, etc.

       It does not, however, come anywhere close to conforming to the CGI "standard". It's actually more like mod_perl in usage, though there are
       several differences.  Most notably, Perlbal is single-process and single-threaded, and handlers run inside the Perlbal process and must
       therefore return quickly and not do any blocking operations.

       As it currently stands, this is very bare-bones and has only really been used with basic GET requests. It lacks a nice API for handling the
       body of a POST or PUT request.

       It is not recommended to use this for extensive applications. Perlbal is first and foremost a load balancer, so if you're doing something
       at all complicated you're probably better off using something like Apache mod_perl and then putting Perlbal in front if it if necessary.
       However, this plugin may prove useful for simple handlers or perhaps embedding a simple HTTP service into another application that uses
       "Danga::Socket".

SYNOPSIS

       This module provides a Perlbal plugin which can be loaded and used as follows.

	       LOAD cgilike
	       PERLREQUIRE = MyPackage

	       CREATE SERVICE cgilike
		       SET role   = web_server
		       SET listen = 127.0.0.1:80
		       SET plugins = cgilike
		       PERLHANDLER = MyPackage::handler
	       ENABLE cgilike

       With this plugin loaded into a particular service, the plugin will then be called for all requests for that service.

       Set cgilike.handler to the name of a subroutine that will handle requests. This subroutine will receive an object which allows interaction
       with the Perlbal service.

	       package MyPackage
	       sub handler {
		   my ($r) = @_;
		       if ($r->uri eq '/') {
			       print "<p>Hello, world</p>";
			       return Perlbal::Plugin::Cgilike::HANDLED;
		       }
		       else {
			       return 404;
		       }
	       }

       Return "Perlbal::Plugin::Cgilike::HANDLED" to indicate that the request has been handled, or return some HTTP error code to produce a
       predefined error message.  You may also return "Perlbal::Plugin::Cgilike::DECLINED" if you do not wish to handle the request, in which case
       Perlbal will be allowed to handle the request in whatever way it would have done without Cgilike loaded.

       If your handler returns any non-success value, it MUST NOT produce any output. If you produce output before returning such a value, the
       response to the client is likely to be utter nonsense.

       You may also return "Perlbal::Plugin::Cgilike::POSTPONE_RESPONSE", which is equivalent to returning zero except that the HTTP connection
       will be left open once you return. It is your responsibility to later call "$r->end_response()" when you have completed the response. This
       style is necessary when you need to perform some long operation before you can return a response; you'll need to use some appropriate
       method to set a callback to run when the operation completes and then do your response in the callback. Once you've called "end_response",
       you must not call any further methods on $r; it's probably safest to just return immediately afterwards to avoid any mishaps.

API DOCUMENTATION

       TODO: Write this

TODO

       Currently there is no API for dealing with the body of a POST or PUT request. Ideally it'd be able to do automatic decoding of
       application/x-www-form-urlencoded data, too.

       The POSTPONE_RESPONSE functionality has not been tested extensively and is probably buggy.

COPYRIGHT AND LICENSE

       Copyright 2007 Martin Atkins <mart@degeneration.co.uk> and Six Apart Ltd.

       This module is part of the Perlbal distribution, and as such can be distributed under the same licence terms as the rest of Perlbal.

perl v5.14.2							    2010-12-20					     Perlbal::Plugin::Cgilike(3pm)