Nathan Van Gheem wrote:
>     So - this looks identical to the "vanilla" example (VIRTUAL_URL,
>     ACTUAL_URL, URL). Does this configuration work as expected?
> Yes.

As an aside, if you're using RewriteEngine anyway, you might as well use 
repoze.vhm#vhm_path. The X-header stuff is mostly useful if you're using 
mod_wsgi. I'm glad we're trying to fix it, though. :)

>     perhaps repoze.zope2 has special handling for the case where
>     repoze.vhm.virtual_root is set and prefixes that to PATH_INFO when it
>     decides what to traverse to? That seems wrong But then, it's set in the
>     vhm_path case too. It is possible that z2bob is doing that prefixing,
>     and we're seeing a traversal like /example/example/a/b/c/d/@@testing,
>     which would work because of acquisition, possibly.
> I assumed it was just acquisition trickery. Looking more closely,
> uses the repoze.vhm.virtual_root via the getVirtualRoot in the
> repoze.vhm.utils package to get the virtual root and it seems to create
> the correct path for traversal regardless of the issue. Just some small
> things are off, like content actions and I just noticed that related
> items don't show also.

Well, if ACTUAL_URL is wrong, then that's a serious bug.

>     I'd try to construct a test case for repoze.vhm that illustrates this.
>     I think you were right that the problem is here:
>     virtual_url_parts += real_path[len(vroot_path):]
> This is kind of why I said earlier that the tests weren't actually
> testing it correctly. We should already be testing for this, it's just
> that the existing tests expect wrong results. The test assumes the
> PATH_INFO does NOT change after the filter application which is wrong.

Right. It happens. :) We should fix those tests. I remember fixing other 
such "wrong" tests before, so I'm not wholly surprised.

> If PATH_INFO is how it decides on what object to traverse to, then we
> should be explicitly setting it in the xheader filter like is done in
> the xpath filter.

I think that'd be safer, but you  may want to ask Chris what he thinks 
as well. Looking at how plain Zope 2 behaves, PATH_INFO is meant to 
contain the full path that Zope is traversing to, virtual hosting or 
not. So maybe, by setting PATH_INFO correctly, we can avoid the 
interplay between repoze.zope2 and repoze.vhm entirely, or at least 
reduce it. I guess setting ACTUAL_URL is still a repoze.zope2 
responsibility, but beyond that, trying to get bits of information from 
repoze.vhm creates a slightly weird dependency across two packages.

> For instance, the only change needed is that the
> filter should look like this,
>     Index: repoze/vhm/
>     ===================================================================
>     --- repoze/vhm/ (revision 7747)
>     +++ repoze/vhm/ (working copy)
>     @@ -85,6 +85,7 @@
>           def __call__(self, environ, start_response):
>               host_header = environ.get('HTTP_X_VHM_HOST')
>               root_header = environ.get('HTTP_X_VHM_ROOT')
>     +        environ['PATH_INFO'] = root_header + environ['PATH_INFO']
>               munge(environ, host_header, root_header)
>               return self.application(environ, start_response)
> along with the tests being fixed.
> I'm sorry if I made this a bigger deal than it really is--seems like a
> simple fix. I've been strapped for time and I'm just trying to do what I
> can...
> Let me know what you think.

This stuff is both complicated and time-consuming to test, so I'm glad 
you've stuck with it. I'd say that if you are able to test both 
configurations with a "real" Zope 2 as well as fix the tests, that'd be 
ideal. I would drop Chris a line if he's not reading this and just ask 
if he has an opinion. I suspect he'll say "I hate Zope 2" and leave you 
to it. In which case, ask for commit access, too. ;)


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Repoze-dev mailing list

Reply via email to