Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

>
> 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. :)

I know that. This is more natural for anyone to use though--I'm setting up a
client with this. Also, I just came across it and thought it should be
fixed

I've gained svn access, created the branch, added tests and made the fix.

I'll test it for a bit and once I feel good about it, merge it to the
trunk.


Thanks for all the help.

-Nathan

On Wed, Dec 30, 2009 at 10:27 AM, Martin Aspeli

> wrote:

> Chris McDonough wrote:
> > Martin Aspeli wrote:
> >>> 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.
> >
> > TBH, I never really understood what ACTUAL_URL was supposed to do.  Limi
> added
> > it at some point, but I'm pretty sure he never really understood what it
> was
> > supposed to do either. ;-)  Or at least he'll deny knowing anything about
> it.
>
> Ah, history...
>
> Limi *wanted* ACTUAL_URL to be "what the user sees", so basically the
> virtual or real URL, *and* the query string, if any.
>
> What he got was something which is basically the same as VIRTUAL_URL if
> that's set, or URL if not. It's still useful, though, since VIRTUAL_URL
> is not set at all if you're not using VHM (in standard Zope). So
> request['ACTUAL_URL'] is a safe way to get "the real URL people see".
> And to get what Alex wanted, you'd need request['ACTUAL_URL'] + '?' +
> request['QUERY_STRING'].
>
> > I'm going to defer to the professionals here; I don't use this package
> much
> > anymore, so you'll need to use some judgment and check in a fix that is
> more
> > correct I think.
>
> I figured. :)
>
> I think Nathan's on the right path, though we just need to do some
> sanity checks with a live running site to be sure.
>
> 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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

Chris McDonough wrote:
> Martin Aspeli wrote:
>>> 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.
>
> TBH, I never really understood what ACTUAL_URL was supposed to do.  Limi added
> it at some point, but I'm pretty sure he never really understood what it was
> supposed to do either. ;-)  Or at least he'll deny knowing anything about it.

Ah, history...

Limi *wanted* ACTUAL_URL to be "what the user sees", so basically the 
virtual or real URL, *and* the query string, if any.

What he got was something which is basically the same as VIRTUAL_URL if 
that's set, or URL if not. It's still useful, though, since VIRTUAL_URL 
is not set at all if you're not using VHM (in standard Zope). So 
request['ACTUAL_URL'] is a safe way to get "the real URL people see". 
And to get what Alex wanted, you'd need request['ACTUAL_URL'] + '?' + 
request['QUERY_STRING'].

> I'm going to defer to the professionals here; I don't use this package much
> anymore, so you'll need to use some judgment and check in a fix that is more
> correct I think.

I figured. :)

I think Nathan's on the right path, though we just need to do some 
sanity checks with a live running site to be sure.

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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Chris McDonough]

Martin Aspeli wrote:
>>
>> 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.

TBH, I never really understood what ACTUAL_URL was supposed to do.  Limi added 
it at some point, but I'm pretty sure he never really understood what it was 
supposed to do either. ;-)  Or at least he'll deny knowing anything about it.

>> 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.

I'm going to defer to the professionals here; I don't use this package much 
anymore, so you'll need to use some judgment and check in a fix that is more 
correct I think.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

>
> So - this looks identical to the "vanilla" example (VIRTUAL_URL,

ACTUAL_URL, URL). Does this configuration work as expected?

Yes.

In your case, PATH_INFO is /a/b/c/d/@@testing. I would've expected it to

be /example/a/b/c/d/@@testing, as it is in the first two examples.

exactly

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.

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.

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. 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.



Thanks,
Nathan

On Wed, Dec 30, 2009 at 7:06 AM, Martin Aspeli

> wrote:

> Nathan Van Gheem wrote:
> > Thanks for the feedback on this. I've set up some tests that I
> > think illustrate what is going on pretty well.
>
>  >> We can get you svn access for sure. :)
> > How can I go about getting that?
>
> Email Chris McDonough. At least that's what I did. ;)
>
> > 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:/a/b/c/d/@@testing
> >
> >
> > Not using wsgi and virtual host monster
> >
> > ---
> >
> >
> > 
> >
> >  ServerName example.com 
> >
> >  ServerAlias example.com 
> >
> >
> >  RewriteEngine On
> >
> >
> >  RewriteRule ^/(.*)
> >
> http://127.0.0.1:8499/VirtualHostBase/http/example.com:/example/VirtualHostRoot/$1
> > [L,P]
> >
> > 
> >
> >
> >
> > VIRTUAL_URL = http://example.com:/a/b/c/d/@@testing
> >
> > PATH_INFO =
> > /VirtualHostBase/http/
> example.com:/example/VirtualHostRoot/a/b/c/d/@@testing
> > 
> >
> > ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
> >
> > URL = http://example.com:/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:/a/b/c/d/@@testing
> >
> > PATH_INFO = /example/a/b/c/d/@@testing
> >
> > ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
> >
> > URL = http://example.com:/a/b/c/d/@@testing
> >
> > SCRIPT_NAME =
> >
> > repoze.vhm.virtual_root = /example
> >
> > repoze.vhm.virtual_url = http://example.com:/a/b/c/d/@@testing
> >
> > repoze.vhm.virtual_host_base = example.com:
> > 
> >
> > HTTP_X_VHM_HOST =
> >
> > HTTP_X_VHM_ROOT =
>
> So - this looks identical to the "vanilla" example (VIRTUAL_URL,
> ACTUAL_URL, URL). Does this configuration work as expected?
>
> > Using wsgi with vhm_xheaders
> >
> > ---

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

Nathan Van Gheem wrote:
> Thanks for the feedback on this. I've set up some tests that I
> think illustrate what is going on pretty well.

 >> We can get you svn access for sure. :)
> How can I go about getting that?

Email Chris McDonough. At least that's what I did. ;)

> 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:/a/b/c/d/@@testing
>
>
> Not using wsgi and virtual host monster
>
> ---
>
>
> 
>
>  ServerName example.com 
>
>  ServerAlias example.com 
>
>
>  RewriteEngine On
>
>
>  RewriteRule ^/(.*)
> 
> http://127.0.0.1:8499/VirtualHostBase/http/example.com:/example/VirtualHostRoot/$1
> [L,P]
>
> 
>
>
>
> VIRTUAL_URL = http://example.com:/a/b/c/d/@@testing
>
> PATH_INFO =
> 
> /VirtualHostBase/http/example.com:/example/VirtualHostRoot/a/b/c/d/@@testing
> 
>
> ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
>
> URL = http://example.com:/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:/a/b/c/d/@@testing
>
> PATH_INFO = /example/a/b/c/d/@@testing
>
> ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
>
> URL = http://example.com:/a/b/c/d/@@testing
>
> SCRIPT_NAME =
>
> repoze.vhm.virtual_root = /example
>
> repoze.vhm.virtual_url = http://example.com:/a/b/c/d/@@testing
>
> repoze.vhm.virtual_host_base = example.com:
> 
>
> HTTP_X_VHM_HOST =
>
> HTTP_X_VHM_ROOT =

So - this looks identical to the "vanilla" example (VIRTUAL_URL, 
ACTUAL_URL, URL). Does this configuration work as expected?

> Using wsgi with vhm_xheaders
>
> 
>
> 
>
>  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:
>
>  RequestHeader add X-Vhm-Root /example
>
> 
>
>
> VIRTUAL_URL = http://example.com:/b/c/d/@@testing
>
> PATH_INFO = /a/b/c/d/@@testing
>
> ACTUAL_URL = http://example.com:/b/c/d/@@testing
>
> URL = http://example.com:/a/b/c/d/@@testing
>
> SCRIPT_NAME =
>
> repoze.vhm.virtual_root = /example
>
> repoze.vhm.virtual_url = http://example.com:/b/c/d/@@testing
>
> repoze.vhm.virtual_host_base = example.com:
> 
>
> HTTP_X_VHM_HOST = http://example.com:
>
> 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.

That suggests that the number of elements chopped up is the same as the 
number of elements in X-VHM-Root. So, there is probably a bug in this 
scenario when:

  - repoze.vhm.virtual_url/VIRTUAL_URL/ACTUAL_URL is being set, and:
  - we have a repoze.vhm.virtual_root

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):]

vroot_path is a list of the elements in the path given by X-VHM-Root, so 
that's where it's chopping off. real_path is a list of the elements in 
PATH_INFO.

This still looks fishy, though. PATH_INFO, as far as I recall, needs to 
contain the full path, from the Zope root. This is what repoze.zope2's 
z2bob is using to traverse (I think...). That code clearly assumes this 
is the case, and so lops off the prefix which should be hidden to the user.

In your case, PATH_INFO is /a/b/c/d/@@testing. I would've expected it to 
be /example/a/b/c/d/@@testing, as it is in the first two examples.

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.

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.repo

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

Maybe I should have explained the tests better then.

All the requests are for the url http://example.com:/a/b/c/d/@@testing and
the plone site as located at "/example" from the zope root.

OK, to analyze the "traditional" Apache + Zope setup:  you are asking

for requests to 'http://example.com/*"; to be rewritten onto the Zope

server at port , with the '/example' folder serving as the virtual

root.  URLs generated by Zope should be relative to that root.  So, the

absolute_url for tha object whose physical path is '/example/foo' should

be 'http://example.com/foo'.  Correct?

Yes

>> Using wsgi with vhm_path

> 


> Same rewrite rule as before (i.e., proxying onto a paste server)?

Yes


>> Using wsgi with vhm_xheaders

>

> 

>

> 

>

> 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:

>

> RequestHeader add X-Vhm-Root /example

>

> 


> You aren't rewriting onto '/example' here, so why are you setting it as

the virtual root?

That's how the xheader filter works. The simple example from the docs shows

ServerName www.example.com

RewriteEngine on

RewriteRule ^/(.*) http://localhost:8080/$1 [P,L]

RequestHeader add X-Vhm-Host http://www.example.com

RequestHeader add X-Vhm-Root /cms


So I am doing it correctly.


>> VIRTUAL_URL = http://example.com:/b/c/d/@@testing

>

> PATH_INFO = /a/b/c/d/@@testing

>

> ACTUAL_URL = http://example.com:/b/c/d/@@testing

>

> URL = http://example.com:/a/b/c/d/@@testing

>

> SCRIPT_NAME =

>

> repoze.vhm.virtual_root = /example

>

> repoze.vhm.virtual_url = http://example.com:/b/c/d/@@testing

>

> repoze.vhm.virtual_host_base = example.com:

>

> HTTP_X_VHM_HOST = http://example.com:

>

> 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.


> I think your configuration is incorrect:  the 'X-Vhm-Root' header is

supposed to signal the "phanotom" path prefix in the URL apparent to the

app.

It is. "/example" is the actual root of zope to prepend every request with.

The site is still serves the correct objects, just some things don't
work completely right. I still think my configuration is correct. If
not, how should it look?


Thanks,
Nathan

On Wed, Dec 30, 2009 at 12:03 AM, Tres Seaver  wrote:

-BEGIN PGP SIGNED MESSAGE-
>
> Hash: SHA1
>
>
> Nathan Van Gheem wrote:
>
> > 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:/a/b/c/d/@@testing
>
> >
>
> >
>
> >> Not using wsgi and virtual host monster
>
> >
>
> > ---
>
> >
>
> >
>
> >> 
>
> >
>
> > ServerName example.com
>
> >
>
> > ServerAlias example.com
>
> >
>
> >
>
> >> RewriteEngine On
>
> >
>
> >
>
> >> RewriteRule ^/(.*)
>
> >>
> http://127.0.0.1:8499/VirtualHostBa

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan Van Gheem wrote:
> 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:/a/b/c/d/@@testing
> 
> 
>> Not using wsgi and virtual host monster
> 
> ---
> 
> 
>> 
> 
> ServerName example.com
> 
> ServerAlias example.com
> 
> 
>> RewriteEngine On
> 
> 
>> RewriteRule ^/(.*)
>> http://127.0.0.1:8499/VirtualHostBase/http/example.com:/example/VirtualHostRoot/$1[L,P]
> 
> 

OK, to analyze the "traditional" Apache + Zope setup:  you are asking
for requests to 'http://example.com/*"; to be rewritten onto the Zope
server at port , with the '/example' folder serving as the virtual
root.  URLs generated by Zope should be relative to that root.  So, the
absolute_url for tha object whose physical path is '/example/foo' should
be 'http://example.com/foo'.  Correct?


>> VIRTUAL_URL = http://example.com:/a/b/c/d/@@testing
> 
> PATH_INFO = /VirtualHostBase/http/
>> example.com:/example/VirtualHostRoot/a/b/c/d/@@testing
> 
> ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
> 
> URL = http://example.com:/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
> 

Same rewrite rule as before (i.e., proxying onto a paste server)?

> 
> VIRTUAL_URL = http://example.com:/a/b/c/d/@@testing
> 
> PATH_INFO = /example/a/b/c/d/@@testing
> 
> ACTUAL_URL = http://example.com:/a/b/c/d/@@testing
> 
> URL = http://example.com:/a/b/c/d/@@testing
> 
> SCRIPT_NAME =
> 
> repoze.vhm.virtual_root = /example
> 
> repoze.vhm.virtual_url = http://example.com:/a/b/c/d/@@testing
> 
> repoze.vhm.virtual_host_base = example.com:
> 
> HTTP_X_VHM_HOST =
> 
> HTTP_X_VHM_ROOT =


>> Using wsgi with vhm_xheaders
> 
> 
> 
> 
> 
> 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:
> 
> RequestHeader add X-Vhm-Root /example
> 
> 

You aren't rewriting onto '/example' here, so why are you setting it as
the virtual root?

>> VIRTUAL_URL = http://example.com:/b/c/d/@@testing
> 
> PATH_INFO = /a/b/c/d/@@testing
> 
> ACTUAL_URL = http://example.com:/b/c/d/@@testing
> 
> URL = http://example.com:/a/b/c/d/@@testing
> 
> SCRIPT_NAME =
> 
> repoze.vhm.virtual_root = /example
> 
> repoze.vhm.virtual_url = http://example.com:/b/c/d/@@testing
> 
> repoze.vhm.virtual_host_base = example.com:
> 
> HTTP_X_VHM_HOST = http://example.com:
> 
> 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.

I think your configuration is incorrect:  the 'X-Vhm-Root' header is
supposed to signal the "phanotom" path prefix in the URL apparent to the
app.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Vers

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

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:/a/b/c/d/@@testing


> Not using wsgi and virtual host monster

---


> 

ServerName example.com

ServerAlias example.com


> RewriteEngine On


> RewriteRule ^/(.*)
> http://127.0.0.1:8499/VirtualHostBase/http/example.com:/example/VirtualHostRoot/$1[L,P]




>
> VIRTUAL_URL = http://example.com:/a/b/c/d/@@testing

PATH_INFO = /VirtualHostBase/http/
> example.com:/example/VirtualHostRoot/a/b/c/d/@@testing

ACTUAL_URL = http://example.com:/a/b/c/d/@@testing

URL = http://example.com:/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:/a/b/c/d/@@testing

PATH_INFO = /example/a/b/c/d/@@testing

ACTUAL_URL = http://example.com:/a/b/c/d/@@testing

URL = http://example.com:/a/b/c/d/@@testing

SCRIPT_NAME =

repoze.vhm.virtual_root = /example

repoze.vhm.virtual_url = http://example.com:/a/b/c/d/@@testing

repoze.vhm.virtual_host_base = example.com:

HTTP_X_VHM_HOST =

HTTP_X_VHM_ROOT =


>
> Using wsgi with vhm_xheaders





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:

RequestHeader add X-Vhm-Root /example






> VIRTUAL_URL = http://example.com:/b/c/d/@@testing

PATH_INFO = /a/b/c/d/@@testing

ACTUAL_URL = http://example.com:/b/c/d/@@testing

URL = http://example.com:/a/b/c/d/@@testing

SCRIPT_NAME =

repoze.vhm.virtual_root = /example

repoze.vhm.virtual_url = http://example.com:/b/c/d/@@testing

repoze.vhm.virtual_host_base = example.com:

HTTP_X_VHM_HOST = http://example.com:

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

> 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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan Van Gheem wrote:
> Seems like Hanno was on the right track here.
> 
> is_view_template is not working correctly because the VIRTUAL_URL is not
> getting set correctly in repoze.vhm. Basically, repoze.zope2 uses the
> environ value of "repoze.vhm.virtual_url" to generate the VIRTUAL_URL. Then
> the actual url is grabbed from that VIRTUAL_URL.
> 
> As far as I can understand, in repoze.vhm.middleware.munge, the lines,
> 
>> real_path = environ['PATH_INFO'].split('/')
> 
> if vroot_path:
> 
> virtual_url_parts += real_path[len(vroot_path):]
> 
> else:
> 
> virtual_url_parts += real_path[1:]
> 
> 
> should simply be,
> 
>> real_path = environ['PATH_INFO'].split('/')
> 
> virtual_url_parts += real_path[1:]

If you have a virtual root, then you *don't* want it to appear in
generated URLs:  it shows up in the URLs bewteen Apache and your app,
but not to outside users.

> I'm probably missing something obvious though. If this is actually an issue
> that isn't specific to my setup, I find it difficult that no one else has
> noticed it prior.

Can you outline your setup?

- - What is the server configured to pass as X-VHM-Root and X-VHM-Host?

- - Does the server set SERVER_NAME?

- - What sub-path, if any, are you serving as the virtual root?



- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks5LOIACgkQ+gerLs4ltQ6aeQCeKJTH6PkymiZkGaxmzOQ4ijEz
AEEAn1ohmOKBtlGdAsZjgtDwCWI5kHGM
=aa/b
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

Looking at this a bit more

So it seems that VIRTUAL_URL and ACTUAL_URL end up being exactly the same in
this setup.

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?

The way the tests are set up, they would show "/example/a/b/c/d"


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.

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.

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.

I doubt that. I think I added the 'if vroot_path' bit to fix a similar

bug, if not the same bug, when using vhm_path. You'll need to svn blame

it and look at what tests were added at the same time, though.

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.

I wish I had more time to do a better job with this. All of your continued
guidance is appreciated.


Thanks,
Nathan

On Mon, Dec 28, 2009 at 4:40 AM, Martin Aspeli

> wrote:

> Hi Nathan,
>
> > is_view_template is not working correctly because the VIRTUAL_URL is not
> > getting set correctly in repoze.vhm. Basically, repoze.zope2 uses the
> > environ value of "repoze.vhm.virtual_url" to generate the VIRTUAL_URL.
> > Then the actual url is grabbed from that VIRTUAL_URL.
> >
> > As far as I can understand, in repoze.vhm.middleware.munge, the lines,
> >
> >  real_path = environ['PATH_INFO'].split('/')
> >
> >  if vroot_path:
> >
> >  virtual_url_parts += real_path[len(vroot_path):]
> >
> >  else:
> >
> >  virtual_url_parts += real_path[1:]
> >
> >
> > should simply be,
> >
> >  real_path = environ['PATH_INFO'].split('/')
> >
> >  virtual_url_parts += real_path[1:]
>
> I doubt that. I think I added the 'if vroot_path' bit to fix a similar
> bug, if not the same bug, when using vhm_path. You'll need to svn blame
> it and look at what tests were added at the same time, though.
>
> > I'm probably missing something obvious though. If this is actually an
> > issue that isn't specific to my setup, I find it difficult that no one
> > else has noticed it prior.
>
> I suspect most people will have used vhm_path instead of vhm_xheaders.
>
> Or it could've been a regression I introduced when fixing this issue
> (and other issues) for the vhm_path use case. :)
>
> 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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

Hi Nathan,

> is_view_template is not working correctly because the VIRTUAL_URL is not
> getting set correctly in repoze.vhm. Basically, repoze.zope2 uses the
> environ value of "repoze.vhm.virtual_url" to generate the VIRTUAL_URL.
> Then the actual url is grabbed from that VIRTUAL_URL.
>
> As far as I can understand, in repoze.vhm.middleware.munge, the lines,
>
>  real_path = environ['PATH_INFO'].split('/')
>
>  if vroot_path:
>
>  virtual_url_parts += real_path[len(vroot_path):]
>
>  else:
>
>  virtual_url_parts += real_path[1:]
>
>
> should simply be,
>
>  real_path = environ['PATH_INFO'].split('/')
>
>  virtual_url_parts += real_path[1:]

I doubt that. I think I added the 'if vroot_path' bit to fix a similar 
bug, if not the same bug, when using vhm_path. You'll need to svn blame 
it and look at what tests were added at the same time, though.

> I'm probably missing something obvious though. If this is actually an
> issue that isn't specific to my setup, I find it difficult that no one
> else has noticed it prior.

I suspect most people will have used vhm_path instead of vhm_xheaders.

Or it could've been a regression I introduced when fixing this issue 
(and other issues) for the vhm_path use case. :)

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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Martin Aspeli]

Hanno Schlichting wrote:
> On Sun, Dec 27, 2009 at 7:21 PM, Nathan Van Gheem  wrote:
>> The page renders completely fine with those actions missing.
>> I stepped into the code a bit and the "plone.contentactions" viewlet isn't
>> even called when repoze.vhm is used.
>
> Hhm, the only slightly funny thing about this viewlet is that it's
> registered for a specific view via the "IViewView" interface.
>
> Can you put a pdb into the Products.CMFPlone.ploneview module where it
> says "if isViewTemplate and not IViewView.providedBy(view):"
>
> Does this differ from the front-page vs. subfolders?
>
> My suspicion would be that maybe the isViewTemplate check fails in one
> case. It's defined in
> plone.app.layout.globals.context.ContextState.is_view_template and
> figures things out based on urls. So the virtual hosting headers might
> influence the result somewhere. Stepping into that method or putting
> another pdb in there might give you some clues.

Yep, that was going to be my suggestion, too.

Which version of repoze.zope2 are you on? I had to fix a bug or two 
there to make this work last time around. We were using 
repoze.vhm#vhm_path, though.

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

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

Seems like Hanno was on the right track here.

is_view_template is not working correctly because the VIRTUAL_URL is not
getting set correctly in repoze.vhm. Basically, repoze.zope2 uses the
environ value of "repoze.vhm.virtual_url" to generate the VIRTUAL_URL. Then
the actual url is grabbed from that VIRTUAL_URL.

As far as I can understand, in repoze.vhm.middleware.munge, the lines,

> real_path = environ['PATH_INFO'].split('/')

if vroot_path:

virtual_url_parts += real_path[len(vroot_path):]

else:

virtual_url_parts += real_path[1:]


should simply be,

> real_path = environ['PATH_INFO'].split('/')

virtual_url_parts += real_path[1:]



I'm probably missing something obvious though. If this is actually an issue
that isn't specific to my setup, I find it difficult that no one else has
noticed it prior.


-Nathan

On Sun, Dec 27, 2009 at 10:45 PM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Nathan Van Gheem wrote:
>
> >  is it possible that it makes an invalid JSON / XML-RPC call when the
> >> virtual hosting is in place?  Can you see anything in Firebug about a
> failed
> >> request?
> >
> > No, everything looks fine.
> >
> > What does render at that point in the page?
> >
> > The page renders completely fine with those actions missing.
>
> Is there anything in the HTML at all there?  Can you add a viewlet
> before or after it which does render?
>
> > I stepped into the code a bit and the "plone.contentactions" viewlet
> isn't
> > even called when repoze.vhm is used.
>
> Is there some kind of predicate / guard condition on that viewlet?  Does
> the authenticated user show up correctly?
>
>
> Tres.
> - --
> ===
> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
> Palladion Software   "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAks3uWkACgkQ+gerLs4ltQ7TvACghzRuOgK15nBBG0/U89vHQxAc
> YiMAoMrOlIv8Lk3K54Z6yOtsRu1Buwiq
> =tlHR
> -END PGP SIGNATURE-
>
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan Van Gheem wrote:

>  is it possible that it makes an invalid JSON / XML-RPC call when the
>> virtual hosting is in place?  Can you see anything in Firebug about a failed
>> request?
> 
> No, everything looks fine.
> 
> What does render at that point in the page?
> 
> The page renders completely fine with those actions missing.

Is there anything in the HTML at all there?  Can you add a viewlet
before or after it which does render?

> I stepped into the code a bit and the "plone.contentactions" viewlet isn't
> even called when repoze.vhm is used.

Is there some kind of predicate / guard condition on that viewlet?  Does
the authenticated user show up correctly?


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks3uWkACgkQ+gerLs4ltQ7TvACghzRuOgK15nBBG0/U89vHQxAc
YiMAoMrOlIv8Lk3K54Z6yOtsRu1Buwiq
=tlHR
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Hanno Schlichting]

On Sun, Dec 27, 2009 at 7:21 PM, Nathan Van Gheem  wrote:
> The page renders completely fine with those actions missing.
> I stepped into the code a bit and the "plone.contentactions" viewlet isn't
> even called when repoze.vhm is used.

Hhm, the only slightly funny thing about this viewlet is that it's
registered for a specific view via the "IViewView" interface.

Can you put a pdb into the Products.CMFPlone.ploneview module where it
says "if isViewTemplate and not IViewView.providedBy(view):"

Does this differ from the front-page vs. subfolders?

My suspicion would be that maybe the isViewTemplate check fails in one
case. It's defined in
plone.app.layout.globals.context.ContextState.is_view_template and
figures things out based on urls. So the virtual hosting headers might
influence the result somewhere. Stepping into that method or putting
another pdb in there might give you some clues.

Hanno
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Nathan Van Gheem]

Hey Tres,

 is it possible that it makes an invalid JSON / XML-RPC call when the
> virtual hosting is in place?  Can you see anything in Firebug about a failed
> request?

No, everything looks fine.

What does render at that point in the page?

The page renders completely fine with those actions missing.

I stepped into the code a bit and the "plone.contentactions" viewlet isn't
even called when repoze.vhm is used.


Thanks,
Nathan

On Sun, Dec 27, 2009 at 9:01 PM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Nathan Van Gheem wrote:
>
> > I'm having some very odd behavior with using repoze.zope2. The site is
> being
> > served using repoze.vhm#vhm_xheaders filter. The correct site is served;
> > however, it seems that content editors can not see the content actions
> drop
> > down menus(Actions, Display, Add new..., etc). More specially, when using
> > repoze.vhm, the "plone.contentactions" viewlet will *NOT* be called on
> any
> > page except the home page.
> >
> > If I remove the repoze.vhm filter, the issue does not occur. I have not
> dug
> > too deep into the issue yet. I kind of wanted to post here and see if
> anyone
> > else has seen this issue and if there is something simple I may be doing
> > wrong.
>
> I don't have ay idea how that viewlet is implemented:  is it possible
> that it makes an invalid JSON / XML-RPC call when the virtual hosting is
> in place?  Can you see anything in Firebug about a failed request?  What
> does render at that point in the page?
>
>
> Tres.
> - --
> ===
> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
> Palladion Software   "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAks3oN0ACgkQ+gerLs4ltQ5bkgCgt1AwOCoN45hXrp1o1OIBs0QE
> 0fIAnRjTbfeVhLyX7OlWknevquXrPp09
> =53zA
> -END PGP SIGNATURE-
>
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.vhm and repoze.zope2 odd behavior

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan Van Gheem wrote:

> I'm having some very odd behavior with using repoze.zope2. The site is being
> served using repoze.vhm#vhm_xheaders filter. The correct site is served;
> however, it seems that content editors can not see the content actions drop
> down menus(Actions, Display, Add new..., etc). More specially, when using
> repoze.vhm, the "plone.contentactions" viewlet will *NOT* be called on any
> page except the home page.
> 
> If I remove the repoze.vhm filter, the issue does not occur. I have not dug
> too deep into the issue yet. I kind of wanted to post here and see if anyone
> else has seen this issue and if there is something simple I may be doing
> wrong.

I don't have ay idea how that viewlet is implemented:  is it possible
that it makes an invalid JSON / XML-RPC call when the virtual hosting is
in place?  Can you see anything in Firebug about a failed request?  What
does render at that point in the page?


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks3oN0ACgkQ+gerLs4ltQ5bkgCgt1AwOCoN45hXrp1o1OIBs0QE
0fIAnRjTbfeVhLyX7OlWknevquXrPp09
=53zA
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev