Hi Nathan, > 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 http://example.com/VirtualHostBase/http/localhost:80/Plone/VirtualHostRoot 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 about that. > 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 that - 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. 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
