![]() |
![]()
| ![]() |
![]()
NAMEPerlbal::Manual::ReverseProxy - Configuring Perlbal as a Reverse Proxy VERSIONPerlbal 1.78. DESCRIPTIONHow to configure a Perlbal Reverse Proxy service. READ ME FIRSTPlease 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 Reverse ProxyConfiguration of Perlbal as a Reverse Proxy is similar to configuration as a Load Balancer. Check Perlbal::Manual::LoadBalancer under "Using Perlbal as a Load Balancer" for a sample configuration file and for a brief explanation of the differences between a Load Balancer and a Reverse Proxy. ParametersYou can set parameters via commands of either forms: SET <service-name> <param> = <value> SET <param> = <value>
More on Parametersbackend_persist_cache vs. connect_ahead The "backend_persist_cache" parameter refers to connections kept alive after being used, while "connect_ahead" refers to connections opened in anticipation. For instance: SET backend_persist_cache = 2 SET connect_ahead = 1 Let's assume, for simplification purposes, that your service only has one server. Here's an example of what could happen:
Reproxying Perlbal supports the concept of reproxying. Basically, this gives it the ability to ask a backend node for a file and get back a specific header that says "this file is really over there, get it there." Perlbal will then load that file or URL and send it to the user transparently, without them ever knowing that they got reproxied to another location. Add the following line to your perlbal.conf to enable reproxying on a per service basis ( reproxying is disabled by default in >= 1.38 ): SET enable_reproxy = true This can be useful for having URLs that get mapped to files on disk without giving users enough information to map out your directory structure. For example, you can create a file structure such as: /home/pics/$userid/$pic Then you can have URLs such as: http://foo.com/mysite/users/$userid/picture/$pic When this URL gets passed to the backend web node, it could return a simple response that includes this header: X-REPROXY-FILE: /home/pics/$userid/$pic Perlbal will then use asynchronous IO to send the file to the user without slowing down Perlbal at all. This support also extends to URLs that can be located anywhere Perlbal has access to. It's the same syntax, nearly: X-REPROXY-URL: http://foo.com:80/resource.html You can also specify multiple URLs: X-REPROXY-URL: http://foo.com:80/resource.html http://baz.com:8080/res.htm Just specify any number of space separated URLs. Perlbal will request them one by one until one returns a response code of 200. At that point Perlbal will proxy the response back to the user just like normal. Note that the user's headers are NOT passed through to the web server. To the target server, it looks simply like Perlbal is requesting the resource for itself. This behavior may change at some point. One final note: the server that returns the reproxy header can also return a "X-REPROXY-EXPECTED-SIZE" header. If present, Perlbal will consider a reproxy a failure if the file returned by the target system is of a different size than what the expected size header says. On failure, Perlbal tries the next URI in the list. If it's a file being reproxied, a 404 is returned if the file size is different. SEE ALSOPerlbal::Manual::Configuration, Perlbal::Manual::FailOver, Perlbal::Manual::LoadBalancer, Perlbal::Manual::Management.
|