Forum OpenACS Q&A: Re: Virtual hosting with AOLserver 4
AOLserver 4.x does have built in virtual hosting but it is not as flexible as nsunix. The main disadvantage is that you can not (re)start individual virtual servers. You can only restart the AOLserver process affecting all virtual servers.
You can however start the AOLserver process with one of the virtual servers (instead of all virtual servers). Don't confuse this with starting individual virtual servers one after another. That is NOT possible.
For these reasons, I've switched to nsvhr TCP/IP based virtual hosting. I plan to write an article about my virtual hosting research.
Drop me a line should you want to give AOLserver 4.x built virtual hosting a try, and I'll send you a sample config file.
I have downloaded the final version of aolserver 4 and I want to try the virtual hosting capabilities.
1. Do you have any sample config file you could send me? There is not documentation I could find about this.
2. Cite 'I plan to write an article about my virtual hosting research'. Do you take the time to do so?
3. Could you give me some advice about using 'nsvhr' instead? I'm reading http://borkware.com/rants/aolserver-vhosting/
4. Another experiences apart from Bart?
Thanks for your help.
I haven't found the time to write down my experiences. Neither have I found a perfect solution. But here's a synopsis of what I've learned so far (all with AOLserver 4.x):
- The build in virtual hosting doesn't allow you to start and stop individual virtual servers. A major drawback in a development environment. Neither does it support HTTPS virtual hosting (with a wildcard certificate).
- nssock/nsvhr works well for HTTP connections but like the build in virtual hosting it doesn't support HTTPS virtual hosting. And all requests to your virtual hosts will be recorded with the IP address of the proxy. The patch listed at http://borkware.com/rants/aolserver-vhosting/ doesn't work for AOLserver 4.x.
- Squid reverse proxy does support HTTPS virtual hosting, including multiple sub-domains with a wildcard certificate. But squid is incapable of passing on to the backend server whether or not the incoming request is on a secure port or not.
- Pound is currently my favorite proxy even though it still can't handle streaming pages. Pound supports HTTPS virtual hosting. Pound can tell OpenACS whether the incoming connection is on a secure port. With a small patch to OpenACS it allows OpenACS to handle those connections as secure connections just like direct HTTPS connections to the backend server.
Bart, interesting info.
What do you mean with: Pound....With a small path to OpenACS
A 'small path'. I don't understand this. Could you explain me, please.
Do you mean a patch?
You say Pound supports HTTPS virtual hosting, but I was reading the Pound webpage at http://www.apsis.ch/pound/index.html and this is what I found.
Virtual Hosts and HTTPS
Quite often we get inquiries about Pound's ability to do virtual hosting with HTTPS. In order to lay this matter to rest, let me say:
HTTPS does not allow virtual hosting
This is not a limitation of Pound, but of HTTPS - no Web server or proxy are able to do it due to the nature of the beast.
Have you find the method to achieve this?
Could you then share a config file or some additional explanation?.
Thank you again.
yes that it is a typo. It should be patch. I plan to commit the patch to CVS when pound has resolved the issue with streaming pages.
I see there exist a mailing list for Pound, but there exist a cvs access or some other link who could be of interest?.
by support for HTTPS virtual hosting I mean that the proxy will handle the SSL connection to then pass on the request to the backend server as a regular HTTP request. The backend server thus never sees the HTTPS connection. And in that sense pound does not proxy HTTPS connections. Which is what the Pound web page is trying to explain.
However, to the client it appears as if it does as the client establishes a secure connection with the proxy and returns the response from the backend server over the established secure connection. As such the client is not aware that the communication between the proxy and the backend server is not encrypted.
Further down the Pound webpage you can read how Pound can accept HTTPS connections and what information it forwards to the backend server in the HTTP connection between Pound and the server.
My patch allows OpenACS to detect a secure connection to Pound based on a custom header added to the information passed from Pound to the server so that OpenACS will treat the connection as a secure connection (e.g. as if it is a direct HTTPS connection). This makes proxied HTTPS connections transparent to OpenACS.