Thanks for the feedback on this. I've set up some tests that I think illustrate what is going on pretty well.
> 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? See below with the test results. > 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. :) How can I go about getting that? 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. Here are the test results.. I've included the apache configuration in there just so you can see what I'm up to. Results ======= > all requests coming on http://example.com:8888/a/b/c/d/@@testing > Not using wsgi and virtual host monster --------------------------------------- > <VirtualHost *:8888> ServerName example.com ServerAlias example.com > RewriteEngine On > RewriteRule ^/(.*) > http://127.0.0.1:8499/VirtualHostBase/http/example.com:8888/example/VirtualHostRoot/$1[L,P] </VirtualHost> > > VIRTUAL_URL = http://example.com:8888/a/b/c/d/@@testing PATH_INFO = /VirtualHostBase/http/ > example.com:8888/example/VirtualHostRoot/a/b/c/d/@@testing ACTUAL_URL = http://example.com:8888/a/b/c/d/@@testing URL = http://example.com:8888/a/b/c/d/@@testing SCRIPT_NAME = repoze.vhm.virtual_root = repoze.vhm.virtual_url = repoze.vhm.virtual_host_base = HTTP_X_VHM_HOST = HTTP_X_VHM_ROOT = > > > Using wsgi with vhm_path ------------------------ VIRTUAL_URL = http://example.com:8888/a/b/c/d/@@testing PATH_INFO = /example/a/b/c/d/@@testing ACTUAL_URL = http://example.com:8888/a/b/c/d/@@testing URL = http://example.com:8888/a/b/c/d/@@testing SCRIPT_NAME = repoze.vhm.virtual_root = /example repoze.vhm.virtual_url = http://example.com:8888/a/b/c/d/@@testing repoze.vhm.virtual_host_base = example.com:8888 HTTP_X_VHM_HOST = HTTP_X_VHM_ROOT = > > Using wsgi with vhm_xheaders ---------------------------- <VirtualHost *:8888> ServerName example.com ServerAlias example.com > RewriteEngine On > RewriteRule ^/(.*) http://127.0.0.1:8499/$1 [P,L] RequestHeader add X-Vhm-Host http://example.com:8888 RequestHeader add X-Vhm-Root /example </VirtualHost> > VIRTUAL_URL = http://example.com:8888/b/c/d/@@testing PATH_INFO = /a/b/c/d/@@testing ACTUAL_URL = http://example.com:8888/b/c/d/@@testing URL = http://example.com:8888/a/b/c/d/@@testing SCRIPT_NAME = repoze.vhm.virtual_root = /example repoze.vhm.virtual_url = http://example.com:8888/b/c/d/@@testing repoze.vhm.virtual_host_base = example.com:8888 HTTP_X_VHM_HOST = http://example.com:8888 HTTP_X_VHM_ROOT = /example It does seem like we have a problem here as its chopping off the first part of the path with the xheaders setup. I'm surprised that the site works as well as it does with this kind of issue. Thanks again, Nathan On Tue, Dec 29, 2009 at 5:04 AM, Martin Aspeli <optilude+li...@gmail.com<optilude%2bli...@gmail.com> > wrote: > 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 >
_______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
