Running a Domino based web application behind a reverse proxy (as I am doing for quite some time now) is the latest craze (due to the SSL issues in the current Domino SSL stack). Sean Cull has instructions for configuring Apache, Jesse Gallagher for ngix.

There is one issue unsolved though in Seans configuration w(that Jesse solved for ngix). The field "Remote_Addr" in the web application will, due to Apache acting as a reverse proxy, not contain the IP of the client calling the app any more. Which can be an issue, if you need that information in your app. The Domino Blog for example can't block clients based on their IP any more.

The solution for that is to set the parameter "HTTPEnableConnectorHeaders=1" either in the notes.ini or a configuration document. With that, Domino maps the following additional headers to the corresponding, regular fields:

$WSAT

The Auth Type that is being used to make this request.

$WSCC

The Client Certificate used for this request. If the value is not base64 encoded for us by the Web server, then the plug-in will base64 encode it before sending it across to the application server.
Restriction: If you enable this, it is assumed you know what you’re doing, and how to protect direct access to the port at which the embedded http is listening.
Note: If you set the LogLevel to TRACE in the plugin XML config file, it is possible to see what headers are actually added for a given request. Appendix C. Domino 6 HTTP plug-in hints and tips 659

$WSCS

The cipher suite that the Web server negotiated with the client. This is not necessarily the cipher suite that the plug-in will use to send the request across to the application server.

$WSIS

This header will be set to either True or False depending on whether or not the request is secure (came in over SSL/TLS).

$WSSC

The scheme being used for the request. This header will normally be set to either http or https.

$WSPR

The HTTP protocol level being used for this request. The plug-in currently has support for up to HTTP/1.1 requests.

$WSRA

The remote IP address of the machine the client is running on.

$WSRH

The remote host name of the machine the client is running on. If the hostname can't be resolved, this header should be set to the IP address.

$WSRU

The remote user specified for the given request.

$WSSN

The server name used for this request. This should be the value that was specified in the HOST header of the incoming request.

$WSSP

The server port that the request was received on. This will be the port value that is used in route determination.

$WSSI

The SSL Session ID being used for this request. If the value is not base64 encoded for us by the Web server, the plug-in will base64 encode it before sending it across to the application server.

So in our case, "$WSRA" would get mapped to the Domino field "Remote_Addr", thereby "fixing" our problem of the missing client IP:

But what have we got to do in order to set  that additional Header in the proxy request from Apache to Domino? The following magic incantation in the correct httpd.conf does the trick:
SetEnvIf REMOTE_ADDR (.*) temp_remote_addr=$1
RequestHeader set "$WSRA" "%{temp_remote_addr}e"
(you need, of course, to enable mod_headers and  mod_setenvif )

This maps the REMOTE_ADDR, containing the clients IP address, to the environment variable "temp_remote_addr", which we then can use to set the $WSRA header in the proxy request. Rinse and repeat for other variables you need.

Simple, isn't it?