Apache support
===============

Currently there are three uwsgi-protocol related apache2 modules available.

mod_uwsgi
---------------

This is the original module. It is solid, but incredibly ugly and does not follow a lot of apache coding convention style.

``mod_uwsgi`` can be used in two ways:

* The "assbackwards" way (the default one). It is the fastest but somewhat far from the Apache2 API.
  If you do not use Apache2 filters (including gzip) for content generated by uWSGI, use this mode.
* The "cgi" mode. This one is somewhat slower but better integrated with Apache. To use the CGI mode, pass ``-C`` to the uWSGI server.

Options
^^^^^^^

.. note::
   
   All of the options can be set per-host or per-location.


**uWSGISocket <path> [timeout]**   Absolute path and optional timeout in seconds of uwsgi server socket.

**uWSGISocket2 <path>**            Absolute path of failover uwsgi server socket

**uWSGIServer <host:port>**        Address and port of an UWSGI server (e.g. localhost:4000)

**uWSGIModifier1 <int>**           Set uWSGI modifier1  

**uWSGIModifier2 <int>**           Set uWSGI modifier2

**uWSGIForceScriptName <value>**   Force ``SCRIPT_NAME`` (app name)

**uWSGIForceCGIMode <on/off>**     Force uWSGI CGI mode for perfect integration with apache filters

**uWSGIForceWSGIScheme <value>**   Force the WSGI scheme var (set by default to "http")

**uWSGIMaxVars  <int>**            Set the maximum allowed number of uwsgi protocol variables (default 128)


To pass custom variables use the ``SetEnv`` directive:

..
  
  SetEnv UWSGI_SCRIPT yourapp


mod_proxy_uwsgi
---------------


This is the latest module and probably the best bet for the future.  It is a
"proxy" module, so you will get all of the features exported by mod_proxy.  It
is fully "apache api compliant" so it should be easy to integrate with the
available modules.  Using it is easy; just remember to load mod_proxy and
mod_proxy_uwsgi modules in your apache config.

.. parsed-literal::

   ProxyPass /foo uwsgi://127.0.0.1:3032/
   ProxyPass /bar uwsgi://127.0.0.1:3033/
   ProxyPass / uwsgi://127.0.0.1:3031/

The first two forms set SCRIPT_NAME respectively to /foo and /bar while the
last one use an empty SCRIPT_NAME. You can set additional uwsgi vars using the
SetEnv directive and load balance requests using mod_proxy_balancer.

.. parsed-literal::

   <Proxy balancer://mycluster>
      BalancerMember uwsgi://192.168.1.50:3031/
      BalancerMember uwsgi://192.168.1.51:3031/
   </Proxy>
   ProxyPass / balancer://mycluster

Pay attention to the last slash in the member/node definition. It is optional
for non-empty SCRIPT_NAME/mountpoints but required for apps mounted in the root
of the domain.  Currently the module lacks the ability to set modifiers, though
this will be fixed soon. An alternative is to set the plugin you want to use as
the first one (0):

.. parsed-literal::

   plugins = 0:php

.. note::

   `mod_proxy_uwsgi` is considered stable starting from uWSGI 2.0.6

.. note::

  If you want to use this module (and help the uWSGI project), report any bugs
  you find, rather than falling back to the ancient (and ugly) mod_uwsgi
  
Starting from Apache 2.4.9, support for Unix sockets has been added. The syntax is pretty simple:

.. parsed-literal::

  ProxyPass / unix:/var/lib/uwsgi/app1.sock|uwsgi://uwsgi-uds-app1/
  ProxyPass / unix:/var/lib/uwsgi/app2.sock|uwsgi://uwsgi-uds-app2/

.. note::

  As per apache documentation, the hostname part of the proxy address is
  ignored. However, if one wants to have different sockets for different apps
  within the same apache instance, the proxy address is used by apache to
  identify different proxy workers: if the proxy address is the same, only
  the firstly declared unix domain socket will get a worker and the secondly
  declared app will have no worker and won't be reachable. A workaround this
  apache limitation (bug?) is to use different hostnames.

mod_Ruwsgi
----------

This module is based on the SCGI module written by Roger Florkowski.

.. note::

  This module is currently undocumented.
