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,
> z2bob.py 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/middleware.py
>
> ===================================================================
>
> --- repoze/vhm/middleware.py (revision 7747)
>
> +++ repoze/vhm/middleware.py (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. ;)
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
