RE: [Zope] Multiple domains from one server process?
[discussion of how apache rewrite rules mess up the PATH_INFO]
I'll have to see if there is anyway to get at the orginal requested URL. If so, a small patch to pcgi/ZPublisher should do the trick. If not, we are deep in trouble, and some hack is needed, where ZPublisher is directed manually how to rewrite the URL back.
What I'd suggest is using ZServer's PCGI server, and adding an option to the PCGI server to tell it to chop a given string from the PATH INFO. This would keep the hack out of Zope's guts.
If this unrolling cann't be done automagically because the environment is completly purged of the orginal url, I'd propose to ways to deal with it, both in ZPublisher
Since apache is not passing the correct PATH_INFO, I'm not sure how Zope would get it besides manual configuration.
-) general: add an toplevel object, that takes some arguments, and in doing so patches URLn and BASEn, etc. to be right. Example: http://www.main.at/killprefix?nr=2&name=www.sub2.at/s/sub2/TEST
Hmm. This seems pretty ugly to me, but I'm not stopping you from writing such an object ;-)
-) programmed: The same thing, but with fixed configured mappings.
I'm not sure what you mean by this.
To come back, why this cannot be done in ZServer and/or pcgi is, that Zope uses always (I didn't check ZServer/ZPublisher, but the Bobo API was like this) CGI to get the specifics about the request, and as such, it does not know ANYTHING about a seperation of logical URL, which is needed for the BASE tag, and physical URL, which is needed for ZPublisher to find the correct object.
I don't really follow this, but ZServer's PCGI server can and does in fact munge the PATH_INFO to get around an IIS bug. So dealing with an Apache rewrite bug seems pretty similar to me.
Let me know if you need more pointers in order to make this work. Sure. How do I configure ZServer to serve PCGI requests? *wonder* How do I configure it at all? And how would you go about implementing this logical/physical URL thing with ZServer?
To configure ZServer read the ZServer/README.txt also run the start script with the -h option: $ python z2.py -h Here's a totally untested patch to PCGIServer.py to accomplish this PATH_INFO munging. It probably doesn't work, but should give you an idea of how it should work ;-) Index: PCGIServer.py =================================================================== RCS file: /cvs-repository/Publishers/ZServer/PCGIServer.py,v retrieving revision 1.6 diff -r1.6 PCGIServer.py 161a162,167
if self.server.path_info_chop: if string.find(self.env['PATH_INFO'], self.server.path_info_chop)==0: self.env['PATH_INFO']=self.env['PATH_INFO'][len( self.server.path_info_chop):]
264c270,271 < logger_object=None): ---
logger_object=None, path_info_chop=''):
283c290,291 < ---
self.path_info_chop=path_info_chop
-Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com
On Mon, 28 Jun 1999, Amos Latteier wrote:
[discussion of how apache rewrite rules mess up the PATH_INFO]
I'll have to see if there is anyway to get at the orginal requested URL. If so, a small patch to pcgi/ZPublisher should do the trick. If not, we are deep in trouble, and some hack is needed, where ZPublisher is directed manually how to rewrite the URL back.
What I'd suggest is using ZServer's PCGI server, and adding an option to the PCGI server to tell it to chop a given string from the PATH INFO. This would keep the hack out of Zope's guts.
If this unrolling cann't be done automagically because the environment is completly purged of the orginal url, I'd propose to ways to deal with it, both in ZPublisher
Since apache is not passing the correct PATH_INFO, I'm not sure how Zope would get it besides manual configuration. Nope. I've found the proposed patch(http://sohodojo.com/forums/Forum14/HTML/000001.html), and Apache can be made to send the orginal URI, by adding the following to the RewriteRule E=ZOPE_RAW_URI:SCRIPT_URI
Than you have the rewritten physical URI, and the real logical URI. Problem solved. Now if we could standardize one ONE environment variable like ZOPE_RAW_URI (or LOGICAL_URI), and then add the support for this to ZServer (when and if ZServer will learn VirtualHosting. Or does it do it already?), then we have a relativly general solution.
-) general: add an toplevel object, that takes some arguments, and in doing so patches URLn and BASEn, etc. to be right. Example: http://www.main.at/killprefix?nr=2&name=www.sub2.at/s/sub2/TEST
Hmm. This seems pretty ugly to me, but I'm not stopping you from writing such an object ;-)
After having played with this stuff on Bobobased systems I won't volunteer either :)
-) programmed: The same thing, but with fixed configured mappings.
I'm not sure what you mean by this. Well, manual regex substitutions before ZPublisher tries to solve the URL.
To come back, why this cannot be done in ZServer and/or pcgi is, that Zope uses always (I didn't check ZServer/ZPublisher, but the Bobo API was like this) CGI to get the specifics about the request, and as such, it does not know ANYTHING about a seperation of logical URL, which is needed for the BASE tag, and physical URL, which is needed for ZPublisher to find the correct object.
I don't really follow this, but ZServer's PCGI server can and does in fact munge the PATH_INFO to get around an IIS bug. So dealing with an Apache rewrite bug seems pretty similar to me. I don't know, I didn't notice any Apache bug :) It's just a logical consequence that by subsiting a Zope site, one creates a split between a physical URL (to locate the right object) and a logical URL (to tell the object which object it is).
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.
participants (2)
-
Amos Latteier -
Andreas Kostyrka