On Sat, 12 Dec 1998, Ronald Offerman wrote:
So BoBoHTTPServer != ZopeHTTPServer? Or is it multithreaded but this feature is not used by Zope? Ok, some history lessons, hopefully I remember right, ... BHS == BoboHTTPServer.py ZHP == ZopeHTTPServer.py BP2 == BoboPOS2 BP3 == BoboPOS3
Ok, Amos orginally wrote BHS as an easy way to activate Bobo Applications. BHS always supported optionally multithreading. pcgi, which at the moment is single-threaded, didn't make me quite happy, single-threaded meaning that I cannot do anything lengthy in a method like creating a tar file, because it blocks the webserver for ALL users, and things like streaming are not possible at all. (1 user a time :( ). Now it happened that my first real Bobo application happens to rely strongly upon streaming to generate it's user interface. I've had to do many ugly things like embedding a Streaming Pseudo HTTPServer in the pcgi process that just serves the streams, etc. The real problem at the moment for Zope is that it uses BP2, which is single-threaded :(, which makes a multithreaded publisher of not much use to Zope users today. The ``split'' between ZHS and BHS stems from two things: -) I've extended BHS to allow publishing via mod_proxy/mod_rewrite. (It's basically allowing to set the idea of the publisher where it is published on the cmdline, instead of deriving it from the HTTP-request) It just happened as a idea to circumvent the no-SSL argument against BHS, when on a lazy sunday I've got bored and started to read the mod_rewrite documentation, ... -) I'm not using Zope, caused of a number of things, at the moment, so I've not patched in Zope Support in my BHS, while Amos did that and renamed it to ZHS. So you have basically two versions of a HTTPServer: -) ZHS with less features. -) my BHS version with more features, but no support for Bobo-the-Z-way, also called ZPublisher *g*
-) pcgi processes run as the Webserver user, so you are limited to uid management a la Apache. BHS runs as the user it is started :) With some small patches to BHS one could even run it as root to allow remote as-root administration of a box.
The proxy stuff has the advantage, that you can hide the real http interface somewhere on the inside (I like to create IP aliases for the loopback device *g*), and all accesses must go trough the external gateway. And this is an invisible redirect. [Off topic:] It would be nice to use the ReWriteEngine to do load balancing over several servers this way ;=)) It can me made quite easily: Assuming that random assignment is enough, than mod_rewrite can already do this, for more complicated stuff you would need a small external (say python) program to generate the URL.
You can even do more complicated stuff, like mapping a session ID into a port number: -) The user ``logs'' in, the central BHS start a child BHS, ... -) The user accesses transparently the child BHS, ... -) Every child BHS knows that it deals with one user :)
That is the reason why I want Zope to be able to send redirects for certain URLs, especially /manage, but others might also come in handy. Redirects are: -) Not so cool, many clients complain about this, ... -) Not so cool, as you need many certificates, consider a website www.X.com, that doesn't need a certificate and is managed via https://www.ISP.com/X/
So by killing the ``Not authorized'' (401?) error code, the user never even gets the possibility to enter a password when working in the clear :) Which should be a strong reminder to switch over to the secure server :) I personally think it is an absolute requirement for Zopes TTW management. But 'killing' the error code is the wrong approach, I would like to see the Yes and no. It's naturally much better to have a more general solution, but I tend to get quite paranoic when I'm wearing my sysadmin hat, so my servers will probably be patched to forbid authentication without SSL.
But then, at the moment my biggest headache and stomache come from POP3 and not httpd :) Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.