Zope, Squid and manage_workspace
I've been pulling my hair out over this one for some time now and followed-up all the appropriate search queries and FAQs etc. With no luck. I now humbly ask help from the assembled crowd. Platform: Zope 2.7.1b1 on Redhat 7.3/i386 "Zope/(unreleased version, python 2.3.3, linux2) ZServer/1.1 Plone/2.0.3" I'm setting up a new ZOPE based site, the world can see it fine and I can manage it as normal. So far so good. If I try the same from inside my company network, all seems to go to plan, until I call /manage_workspace against any object, then I get no response returned. The bizarre thing is I can call /manage_main against anything, no problem. ONLY /manage_workspace fails. The only difference between world access and internal access that I can figure out is our company squid proxy. This is not being used as a local HTTP accelerator for ZOPE but as a simple mandatory company-wide proxy for all web traffic.
From grepping the squid.log it seems that squid forwards the request to the ZOPE server fine but never receives or acknowledges the ZOPE reply.
Just as a comparison, using an Apache front-end to ZOPE with ProxyPass works fine (dunno why), but I can't pursue this as a solution as it cannot be seen externally to the company, again dunno why :-( Can anyone shed light on this please, any similar experiences? -- Eddie
Eddie Butcher wrote at 2004-6-12 15:30 +0100:
... If I try the same from inside my company network, all seems to go to plan, until I call /manage_workspace against any object, then I get no response returned.
The bizarre thing is I can call /manage_main against anything, no problem. ONLY /manage_workspace fails.
The difference between "manage_workspace" and "manage_main" (for a folder) is the "manage_workspace" (usually) performs a redirect to "manage_main". Apparently, this redirect fails -- maybe, because the URL is a Zope URL and not a SQUID URL. Did you set up SQUID and Zope to use URL rewriting and VHM? -- Dieter
In article <16588.12977.831567.945324@gargle.gargle.HOWL>, Dieter Maurer wrote:
The difference between "manage_workspace" and "manage_main" (for a folder) is the "manage_workspace" (usually) performs a redirect to "manage_main".
Oh Yes, ZOPE responds with an HTTP 302
and VHM?
I haven't set a VHM as there are not yet any virtual hosts within ZOPE. Surely I don't need a VHM for the / directory, it already resolves to a true DNS name that I use to manage the site. I tried creating a SiteRoot in / that matches the DNS name but it didn't help.
Did you set up SQUID and Zope to use URL rewriting
I've looked at all the Squid docs and FAQs I can find, if you could point me at something to read, I'd be grateful. -- Eddie
Eddie Butcher wrote at 2004-6-13 15:02 +0100:
... "manage_workspace" and "manage_main" work directly accessed; "manage_main" does, when accessed via Squid, "manage_workspace" does not ...
... I haven't set a VHM as there are not yet any virtual hosts within ZOPE. Surely I don't need a VHM for the / directory, it already resolves to a true DNS name that I use to manage the site. I tried creating a SiteRoot in / that matches the DNS name but it didn't help.
Zope usually listens on a port different from 80 (as this is protected and requires a process running as root). Therefore, the URLs it creates contain its port and not that of Squid. A SiteRoot might be enough to fix the port. But, I never used "SiteRoot"s and much prefer VHM. You can configure VHM to perform its actions without external URL rewriting. VHM is documented on a tab of VHMs ZMI.
Did you set up SQUID and Zope to use URL rewriting
I've looked at all the Squid docs and FAQs I can find, if you could point me at something to read, I'd be grateful.
I am no Squid expert. I know only what I read in the Zope mailing lists ;-) What I understood: Squid does not directly support URL rewriting but can call external URL rewriters (and there are such rewriters implemented in Python). As you do not really use virtual hosting, there is probably no need to perform URL rewriting by Squid. -- Dieter
Dieter Maurer wrote:
Zope usually listens on a port different from 80 (as this is protected and requires a process running as root). Therefore, the URLs it creates contain its port and not that of Squid.
Which makes me wonder; why does Zope do this in the first place? Why isn't its default behavior to only create relative URLs that won't have the hostname and port in them? Why does it, by default, insert the BASE tag with a hostname and port number into documents? I don't remember ever having this behavior when writing web apps with Tomcat or Apache. For sure, this makes it harder for Zope-generated content to be modular and integrated into a site (and hence all the never-ending questions about mod-rewrite, VHM, etc.) I've currently got it all working, but because of Zope, I have to relearn them every year or two... Robb
On Sun, 2004-06-13 at 17:14, Robb Shecter wrote:
Which makes me wonder; why does Zope do this in the first place? Why isn't its default behavior to only create relative URLs that won't have the hostname and port in them? Why does it, by default, insert the BASE tag with a hostname and port number into documents?
It's a long and gory story. The general idea is that, because only Zope knows whether a traversed object is "containerish", the request URL doesn't end with a slash, it needs some way to tell the browser how to render relative URLs in the context of the returned output. The best detailed explanation I know of as to why the BASE tag is the only sane solution without redirects is here: http://mail.zope.org/pipermail/zope-coders/2001-November/000460.html A saner way would be to cause a redirect to a slash-ending name when a containerish object is displayed, but no one has stepped up to make this a possibility. - C
Robb Shecter wrote at 2004-6-13 17:14 -0400:
Dieter Maurer wrote:
Zope usually listens on a port different from 80 (as this is protected and requires a process running as root). Therefore, the URLs it creates contain its port and not that of Squid.
Which makes me wonder; why does Zope do this in the first place? Why isn't its default behavior to only create relative URLs that won't have the hostname and port in them?
Because it follows the official specifications: Base tags and the "location" in redirects must be absolute URLs. All browsers I met so far do not insist on this -- but a browser could do it.
... URI in "base" tag ...
From the HTML 4.01 specification:
: This attribute specifies an absolute URI that acts as the base : URI for resolving relative URIs. -- Dieter
In article <16588.35209.848748.871547@gargle.gargle.HOWL>, Dieter Maurer wrote:
A SiteRoot might be enough to fix the port. But, I never used "SiteRoot"s and much prefer VHM.
I found the solution in the end. It turns out that there was one more link in the chain that I wasn't aware of. All traffic goes through an IBM firewall/proxy. The 302 redirect that ZOPE was returning was being blocked by the firewall. The reason was that the reply did not conform to strict HTTP and was therefore stopped. I had to edit HTTPRepsonse.py to append some dummy HTML to make the reply compliant. All works fine now, all over the World. Might be worth making the change in the ZOPE src itself. -- Eddie
participants (4)
-
Chris McDonough -
Dieter Maurer -
Eddie Butcher -
Robb Shecter