Resin includes its own powerful HTTP server which features comparable performance to C-based servers such as Apache or nginx without the overhead of requiring multiple processes. Using the Resin HTTP server is recommended. In addition to its solid performance, the Resin HTTP server also has a number of convenient features for configuring SSL, rewriting requests, and managing virtual hosts.
OpenSSL
One of Resin Professional's most useful features is OpenSSL integration which offers far faster SSL performance than pure Java solutions. To configure OpenSSL, add an <http> tag with an <openssl> tag to your server configuration:
<resin xmlns=“http://caucho.com/ns/resin” xmlns:resin=“urn:java:com.caucho.resin”>
<cluster id=“app-tier”>
<server id=“” address=“192.168.0.10” port=“6800”>
<http port=“443”>
<openssl>
<certificate-file>example.crt</certificate-file>
<certificate-key-file>example.key</certificate-key-file>
<password>my-password</password>
</openssl>
</http>
</server>
</cluster>
...
</resin>
Rewrite Dispatch
Resin offers a URL rewriting mechanism similar to Apache's mod_rewrite in its HTTP server. Rules for rewriting URLs can be configured on an application, host, server, or cluster level. For example, you may want to allow all requests for specific static resources (such as images, CSS, JavaScript, etc.) to be served as usual, but redirect all other requests to a central controller Servlet. You could achieve that within your resin-web.xml with the following configuration:
<web-app xmlns=“http://caucho.com/ns/resin” xmlns:resin=“urn:java:com.caucho.resin”>
<resin:Dispatch regexp=“\.(php|js|gif|png|css|html)$”/>
<resin:Dispatch regexp=“^” target=“/controller”/>
</web-app>
The <resin:Dispatch> tag here is an internal redirection (i.e. the request is passed within the server without an HTTP redirect). You can use tags for HTTP forwarding, FastCGI integration, load balancing, and more:
| Tag |
Behavior |
| <resin:Dispatch> |
Redirect a request internally |
| <resin:Redirect> |
Send an HTTP redirect |
| <resin:Forbidden> |
Send an HTTP forbidden response |
| <resin:Forward> |
Send an HTTP forward |
| <resin:FastCgiProxy> |
Redirect requests to a backend FastCGI process |
| <resin:HttpProxy> |
Redirect requests to a backend HTTP service |
| <resin:LoadBalance> |
Redirect the request to a backend cluster for processing |
Virtual Hosts
For many deployments, you may not need to use specialized virtual hosts (e.g. you only use example.com and www.example. com). In these cases, you can deploy to the standard web app deploy directory and Resin will serve all your applications regardless of the virtual host specified by the client.
If you have a deployment with more virtual hosts however (store.example.com, blog.example.com, etc.), you'll need to organize your applications in the appropriate virtual hosts. Virtual hosts are a native concept to Resin and you can create them two different ways:
- Use Resin's host deploy directory
- Create an explicit host with the <host> tag in resin.xml
The host deploy directory allows you to create a directory structure such as:
/var/www/hosts/store.example.com/webapps
Then any applications deployed in this webapps directory will be served from Resin as store.example.com.
You may prefer to use an explicit <host> tag in your resin.xml. This approach allows you to create a custom directory structure and make your hosts explicit in configuration.
