www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott.pichel...@weirslurry.com
Subject Fw: Apache2 Proxy and Domino Http Server Webmail Redirect
Date Fri, 07 Jan 2005 16:12:23 GMT

I have been trying to get apache's modproxy(ProxyPass/Reverse) or even 
Modrewrite(RewriteCond/Rules) to work properly with Domino's 
WebmailRedirect.nsf file.

Here is a Notes forum Post that hopefully explains the problem I am having 
in a nutshell:

An explaination of my scenario below:
All behind our Firewall - PIX515:

        User(Internet) --> FW --> Apache2 WebServer(DMZ) --> Domino Http 
Server(COMM-different network) 

Starting from the backend first...
The domino Web server is running on  port 81 and it's Home URL is "
/DominoWe.nsf". ( I believe this file has code or references the Webmail 
redirect db/code)
We are using an IBM/Lotus supplied Domino Webmail "redirect" called 
If I use the Domino webserver address & port to access webmail it works 
A single sign-on and we are redirected to our mail file without any 
problems.(The redirect takes the info given with username/pwd from 
names.nsf and any other files & directs the browser to the mail/*.nsf and 
loads up webmail interface/template)

However, it's get's more complex as you know when we add Apache2 and its 
Reverse Proxy into the mix.
I have tried using modrewrite w/ rewriterules and I get the same result. ( 
I tried your method and many others as well)

RewriteEngine on
RewriteLog "/var/log/httpd/rewrite.log"
RewriteLogLevel 2
RewriteCond %{REQUEST_URI} ^/
RewriteRule /(.*)$1 [P]

And with a Pound Proxy added to the configuration, just these two Proxy 
directives worked for me!

ProxyPass /
ProxyPassReverse /

The IP's listed above are of course the backend Domino Server.
So, as you can see I didn't need modrewrite w/ rewriterules or 
The reason why is because a used another reverse proxy called "Pound".
URL located below:

Then, for the above ProxyPass/Reverse directives I had the IP and port of 
the Pound Proxy and the Pound Proxy had the values of the Domino server:

ProxyPass / https://webmail.weirslurry.com:8080/
ProxyPassReverse / http://webmail.weirslurry.com:8080/


Another rudimentary  diagram below:
User(Internet) --> FW --> Apache Web Server/Proxy & Pound Proxy on same 
machine(DMZ - behind FW) --> Domino Http Server(COMM-another different 
network behind FW) 

So, somehow the addition of the Pound Proxy helped the Http 
headers/URI/URL's,etc understand teh DominoWEbmailRedirect in Domino Http 
so it would ask for our username and pwd "only" once and not reveal the IP 
address of the backend Domino server after serving up the webmail 
I know it sounds strange, but it works.

In conclusion, my issue is with the Domino Redirect.
If I could write  home-grown html, php, perl, jsp or ? script/code with my 
own "redirect" I would think that apache would behave better?
I found some examples of creating a work-around or a homegrown solution in 
the Notes forums where others have had the same problem but the 
explanations & answers weren't clear for me.
Here are some examples:
None of which seem to work for me!?!

And this last one I would like to try but haven't given it any thought or 
know how to start w/ Lotus forms/agents...

Should I be using vhosts and then add some rewriterules together in order 
to remedy my problem?
If you are still confused I can allow you access the Domino Web server 
Webmail front-end I am working on from the net.
I appreciate any feedback, thanks!


Scott Pichelman
Systems Administrator
Weir Slurry TM
North America
2701 S Stoughton Rd
Madison WI 53716  USA

T: +001 608 226 5615
F: +001 608 221 5807
M: +001 608 346 2784
E: scott.pichelman@weirslurry.com
W: http://weirslurry.com

The information contained in this email (including any attachments) is confidential, subject
to copyright and for the use of the intended recipient only. If you are not the intended recipient
please delete this message after notifying the sender. Unauthorised retention, alteration
or distribution of this email is forbidden and may be actionable.

Attachments are opened at your own risk and you are advised to scan incoming email for viruses
before opening any attached files. We give no guarantee that any communication is virus-free
and accept no responsibility for virus contamination or other system loss or damage of any

View raw message