On Mon, 28 Jun 1999, Amos Latteier wrote:

...

...

That's a problem we've been having. Currently our customers are using similar tricks to the one you've posted to get around it. It's related to the way mod_rewrite works, we think anyways. Some one has posted a fix that patches ZPublisher, haven't had a chance yet to try it though. Nope, I actually think this is a logical problem. When redirecting to Zope.cgi/path/path/$1 path/path/ gets added by Apache to the request URL, as it needs to communicate that fact to the CGI program.

Now Zope takes the servername, which is reported correctly as www.subdomain.com, and sticks it together with the full path, /path/path/someurl.

I'll hunt for the ZPublisher patch and try it, because it sounds as a good place to help this problem.

I'm not sure that ZPublisher is the right place to solve this. If I understand correctly, you are looking for a way to chop some fixed string '/path/path' off the front of the PATH_INFO for every request. I would guess that doing this in ZServer rather than in ZPublisher might be a better idea. Nope. The right place is probably ZPublisher, as it happens to be the same old game that I've done to BoboHTTPServer (running on real host:port, pretending to be host:port/dir for Bobo).

What basically happens is the following. First an example Apache config, showing only the important things: <VirtualHost> ServerName www.main.at RewriteRule ^/(.*) /home/zope/Zope.cgi/$1 </VirtualHost> <VirtualHost> ServerName www.sub1.at RewriteRule ^/(.*) /home/zope/Zope.cgi/s/sub1/$1 </VirtualHost> <VirtualHost> ServerName www.sub2.at RewriteRule ^/(.*) http://www.main.at/s/sub2/$1 </VirtualHost> So we have basically three sites, one standalone, and two hosted inside a folder object of the first. I've included sub2 too, because it explains the problem better. When accessing http://www.sub2.at/TEST pcgi sees the environment as if http://www.main.at/s/sub2/TEST was accessed. To make the thing more complicated, the more common case of www.sub1.at makes pcgi believe it is accessed as http://www.sub1.at/s/sub1/TEST 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. 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: -) 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 -) programmed: The same thing, but with fixed configured mappings. 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.

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?

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.