> So it seems that VIRTUAL_URL and ACTUAL_URL end up being exactly the
> same in this setup.
Yes, that's probably to be expected.
ACTUAL_URL is basically "the URL the user sees". In a path based VHM
setup, that's http://example.com when your internal URL is
In a header-based VHM setup, you don't have path munging, so if Apache
is hosted on http://example.com, ACTUAL_URL is too.
VIRTUAL_URL is the URL after VHM translation, so in most cases
VIRTUAL_URL and ACTUAL_URL will be the same. With vhm_xheaders, they're
basically set to be exactly the same, I think, as in
environ['ACTUAL_URL'] = environ['VIRTUAL_URL'], though I could be wrong
> Also, I'm looking at the tests in the repoze.vhm package, and it seems
> the only reason why the tests pass is because they are using an
> incorrect PATH_INFO. I'll try and setup an example and show what I mean,
> vhm host = http://example.com/
> vhm root = /example
> request = http://example.com/a/b/c/d
> PATH_INFO should be "/a/b/c/d" right?
No, I don't think so - see below.
> The way the tests are set up, they would show "/example/a/b/c/d"
PATH_INFO is supposed to be the path from the root of the Zope instance
as far as I recall, so (I'm pretty sure) it should *include* the bits
that are gobbled up by virtual hosting. PATH_INFO is what tells the
publisher where to traverse to from the root of the site. If it didn't
have the /example prefix, it wouldn't be able to traverse into the Plone
site (or whatever your VHM root is).
That is, environ['SERVER_URL'] + environ['PATH_INFO'] are *not*
necessarily going to equal environ['ACTUAL_URL']
> The reason this is a problem is because the "repoze.vhm.virtual_url"
> value which makes the VIRTUAL_URL which makes the ACTUAL_URL is made
> from the PATH_INFO, and if you're assuming the PATH_INFO to be something
> that it is not, you're just writing passing tests instead of writing tests.
Yes that is a risk. You'll need to test, I guess. What I can tell you is
- this is confusing and difficult to remember
- I spent a lot of time on this trying to make these things work for
repoze.vhm#vhm_path, and writing (and fixing) tests. That's not to say
there aren't "wrong" tests, but at least you need to pdb through
repoze.vhm and into repoze.zope2 to understand what's going on.
> What ends up happening in the current situation is that a url of
> "/a/b/c/d" get chopped off to something like "/b/c/d" NOT including the
> virtual root.
Sorry, where is this happening?
> I hate to go through it like this. I don't have svn access though and
> either I'm completely misunderstanding something or this is a rather
> ugly bug.
We can get you svn access for sure. :)
> I blame'd it and it seems that the change was introduced with the things
> needed for the repoze.zope2 1.0.2 release which relied gave more
> credence to repoze.vhm if I understand it correctly. Nothing in the log
> or tests, as far as I can tell, explains that it fixes a bug though.
Perhaps I'm mistaken. :)
> I wish I had more time to do a better job with this. All of your
> continued guidance is appreciated.
It is annoying. My suggestion would be:
- Try the same setup with a "standard" Zope and vhosting via the old
VirtualHostMonster, just to have a baseline. Write a simple view that
prints the request (in particular the keys VIRTUAL_URL, PATH_INFO,
ACTUAL_URL and URL)
- Use the same view in a setup that uses repoze.vhm#vhm_path and a
rewrite rule. Are you getting the same behaviour?
- Use the same view in a setup that uses repoze.vhm#vhm_xheaders and
set headers. Are you getting the same behaviour?
Maybe the first setup would take some time to set up, but using a
rewrite rule + vhm_path should be a minor change from using custom
headers and vhm_xheaders. At least then we can find out where, if
anywhere, there are differences. Then we can dig deeper.
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