[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi Stefan!

Stefan H. Holek wrote:
absolute_url(1) was broken (by my definition of broken) basically since  
the introduction of VHM, which means the better part of 2 years.  
Naturally, there is code now that relies on this (broken) behavior.  
This does however not mean it should not be fixed!
AFAICT 'inside-out' hosting was used long before the introduction of 
VHM. Using your definition of broken absolute_url(1) was broken since 
the introduction of CGI scripts, which means longer than Zope has its 
current name.

[...]
The idiom '/'+absolute_url(1) to get the path part of an object's URL  
is *very* common, and as luck will have it *works absolutely fine* as  
long as inside-out hosting is not present. So this error usually goes  
undetected and creeps all over people's code. I'd be willing to bet  
that it is possible to break other packages like, say, Plone simply by  
changing Vhost configs as well ;-).

Note that this is one of my main points: It will be of little use to  
document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1)  
appears to work (until it is far too late).
I can see why you think the API should be changed. But do you really 
think it is the Right Thing to break existing products of people who 
read the API documentation and tested their products carefully to fix 
the products of people who trusted their intuition?

Cheers,
Yuppie


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Jamie Heilman]

Toby Dickenson wrote:
> Because
> 
> /
> 
> looks nicer than without the slash
> 
> ?

OT: Seeing as that would actually have to be written
/
to get anywhere close to reliable and secure behavior, calling
dtml-anything "nice" seems to be a bit moot--bug 813 lives on.

...but anyway, I have no opinion on the absolute_url api one way or
the other, its been so carry on...

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Toby Dickenson]

On Monday 08 December 2003 21:21, Paul Winkler wrote:
> On Mon, Dec 08, 2003 at 08:24:04PM +0100, Dieter Maurer wrote:
> > Maybe, my contribution has not been read. Thus, I try again:
> >
> >"/" + "absolute_url(1)" should implement the notion
> >of "absolute-path URL reference" (see RFC2396 section 5).
> >
> >This means, that the receiving browser should be able
> >to retrieve the object correctly given this URL reference.
>
> Yup.
> But while we're on the subject...
> Why doesn't absolute_url(1) include a leading slash?
> I don't think I've ever seen a use of absolute_url(1)
> that didn't have to add the slash. What was the rationale
> originally?

Because

/

looks nicer than without the slash

?

-- 
Toby Dickenson


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Paul Winkler]

On Mon, Dec 08, 2003 at 08:24:04PM +0100, Dieter Maurer wrote:
> Maybe, my contribution has not been read. Thus, I try again:
> 
>"/" + "absolute_url(1)" should implement the notion
>of "absolute-path URL reference" (see RFC2396 section 5).
> 
>This means, that the receiving browser should be able
>to retrieve the object correctly given this URL reference.

Yup.
But while we're on the subject...
Why doesn't absolute_url(1) include a leading slash?
I don't think I've ever seen a use of absolute_url(1)
that didn't have to add the slash. What was the rationale
originally?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's ZOOMING SOLITARY PICNINC CHLAMYDIA  OOZE!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Dieter Maurer]

Stefan H. Holek wrote at 2003-12-8 12:35 +0100:
> ...
>The ugly part is that the behavior of absolute_url(1) changes suddenly  
>when the Vhost configuration starts to include inside-out parts  
>(_vh_xyz). This means that is is possible to break (seemingly) working  
>code by reconfiguring Apache. :-(

Maybe, my contribution has not been read. Thus, I try again:

   "/" + "absolute_url(1)" should implement the notion
   of "absolute-path URL reference" (see RFC2396 section 5).

   This means, that the receiving browser should be able
   to retrieve the object correctly given this URL reference.

-- 
Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Lennart Regebro]

Paul Winkler wrote:
See the "About" tab on VHM.
OK, good.


"Inside out" is mentioned
numerous times in this thread.
Yeah, I know, but I was getting confused to what it actually ment.

The result that I got by doing BASEPATH1+'/'+absolute_url(1)
as described in my previous message. I thought that was clear.
Now it is. :) Thanks.

//Lennart

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Paul Winkler]

On Mon, Dec 08, 2003 at 05:58:12PM +0100, Lennart Regebro wrote:
> Paul Winkler wrote:
> >As a frequent (ab)user of '/'+absolute_url(1), which did indeed
> >bite me when i deployed to an "inside out" apache setup,
> >I thought I'd try this out... I think you 
> >meant BASEPATH1+'/'+absolute_url(1)?
> 
> I would like to know:
> 1. Exactly what is an "inside out" apache setup.

See the "About" tab on VHM. "Inside out" is mentioned
numerous times in this thread.

> 2. What is the result you want?

The result that I got by doing BASEPATH1+'/'+absolute_url(1)
as described in my previous message. I thought that was clear.

BASEPATH1 does not have a trailing slash, and
absolute_url(1) does not have a leading slash, so if you
visit _vh_foo/bar you will get foobar instead of foo/bar.
Therefore, BASEPATH1 + absolute_url(1) does not work.
You have to insert the slash.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's LATE HYDROXY WATERBOY!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Lennart Regebro]

Paul Winkler wrote:
As a frequent (ab)user of '/'+absolute_url(1), which did indeed
bite me when i deployed to an "inside out" apache setup,
I thought I'd try this out... I think you 
meant BASEPATH1+'/'+absolute_url(1)?
I would like to know:
1. Exactly what is an "inside out" apache setup.
2. What is the result you want?


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Toby Dickenson]

On Monday 08 December 2003 11:35, Stefan H. Holek wrote:

> Note that this is one of my main points: It will be of little use to
> document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1)
> appears to work (until it is far too late).

We can fix this social problem by providing an easy way for product developers 
to run their development zope server with the virtual path equivalent to an 
inside-out hosting configuration. easy means not needing apache/squid.

Our staging server is uses an inside-out virtual host configuration (to 
simplify ssl certificate management) so we hit all these problems early 
enough to fix the damage cheaply.


-- 
Toby Dickenson


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Paul Winkler]

On Mon, Dec 08, 2003 at 12:35:38PM +0100, Stefan H. Holek wrote:
> Note that this is one of my main points: It will be of little use to  
> document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1)  
> appears to work (until it is far too late).

As a frequent (ab)user of '/'+absolute_url(1), which did indeed
bite me when i deployed to an "inside out" apache setup,
I thought I'd try this out... I think you 
meant BASEPATH1+'/'+absolute_url(1)?

I put this in a page template called test_abs_url:

  Typical relative path using absolute_url(1): 
   
  
  BASEPATH1 is:  
  Better relative path using BASEPATH1 and absolute_url(1): 
   
  


If I visit this at http://localhost:8080/ctimi/about/test_abs_url, I get:


 Typical relative path using absolute_url(1): /ctimi/about

 BASEPATH1 is:

 Better relative path using BASEPATH1 and absolute_url(1): ctimi/about 

  ^^
note, no leading slash

If I visit 
http://localhost:18080/VirtualHostBase/http/www.foobar.com:80/VirtualHostRoot/_vh_foo/ctimi/about/abs_url_test
I get this:


 Typical relative path using absolute_url(1): /ctimi/about

 BASEPATH1 is: /foo

 Better relative path using BASEPATH1 and absolute_url(1): /fooctimi/about 


... definitely not right.
But your point is made - '/'+absolute_url(1) is clearly inadequate too.

If I change the template to use request['BASEPATH1']+'/'+here.absolute_url(1),
then I get this:


 Typical relative path using absolute_url(1): /ctimi/about

 BASEPATH1 is: /foo

 Better relative path using BASEPATH1 and absolute_url(1): /foo/ctimi/about 


... which looks correct to me.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's CHEESY ENGINEER!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Lennart Regebro]

Leonardo Rochael Almeida wrote:
IMHO, this is broken behaviour. If you try to use an URL to locate an
object, the only sane behaviour is to feed this URL to an URL api
(probably in the REQUEST object) to get it mapped to a physical path.
(Un)RestrictedTraverse can do this, right? Or does that require the full 
physical Path/URL?

On Mon, 2003-12-08 at 09:35, Stefan H. Holek wrote:
P.S.: I have written a bunch of regression tests for absolute_url  
behavior over the weekend and if nobody tells me otherwise am going to  
check them into Products/SiteAccess/tests.
I think this is a good idea. In any case I'd like them, to adapt them to 
the getXXPath API's, which I think I'll check in tomorrow. They are 
really trivial methods, but it would be good to have unit tests for API 
documentation. :)

//Lennart

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Leonardo Rochael Almeida]

On Mon, 2003-12-08 at 09:35, Stefan H. Holek wrote:
> [...]
> So by my definition, the URL (relative or not) should *always* include  
> eventual _vh_xyz parts. If what one really needs is related to the  
> physical layout of the ZODB, there is always getPhysicalPath().

+1

> URLs are in fact just some whack attributes of objects, and objects can  
> have more than one URL at any time, depending on Vhost configs *only*.  
> URLs are a function of the current REQUEST (traversal) and do represent  
> little information with regard to an object's location in the ZODB.

+1

> I see the main issue here in that the concepts of URL and physical  
> location are not well separated (CMF's getIcon() attempting to use URLs  
> to locate objects for example).

IMHO, this is broken behaviour. If you try to use an URL to locate an
object, the only sane behaviour is to feed this URL to an URL api
(probably in the REQUEST object) to get it mapped to a physical path.

> Should this be your last word on this I am with Lennart in that we have  
> to think about a whole new class of API methods for URL information.

I think this should be done anyway, because of backward compatibility
problems. Really, I think it's ok if at some point we simply say "hey,
now we'll use this new API because that old API was broken and people
relied on the broken behaviour". This is certainly better than pulling
people's rug under their feet. We could then start deprecating the old
API and eventually pull it away, if the arrival of Zope3 doesn't obviate
it anyway :-)


> P.S.: I have written a bunch of regression tests for absolute_url  
> behavior over the weekend and if nobody tells me otherwise am going to  
> check them into Products/SiteAccess/tests.

+5 Yes, please!

As the author of ASP404, I'd really like to be able to rely on Zope's
virtual hosting behaviour.

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Stefan H. Holek]

Evan,

absolute_url(1) was broken (by my definition of broken) basically since  
the introduction of VHM, which means the better part of 2 years.  
Naturally, there is code now that relies on this (broken) behavior.  
This does however not mean it should not be fixed!

The ugly part is that the behavior of absolute_url(1) changes suddenly  
when the Vhost configuration starts to include inside-out parts  
(_vh_xyz). This means that is is possible to break (seemingly) working  
code by reconfiguring Apache. :-(

I had some very bad experiences with big packages like CPS2 that  
suddenly exploded in my face at the worst possible time (deployment at  
the customer's site).

The idiom '/'+absolute_url(1) to get the path part of an object's URL  
is *very* common, and as luck will have it *works absolutely fine* as  
long as inside-out hosting is not present. So this error usually goes  
undetected and creeps all over people's code. I'd be willing to bet  
that it is possible to break other packages like, say, Plone simply by  
changing Vhost configs as well ;-).

Note that this is one of my main points: It will be of little use to  
document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1)  
appears to work (until it is far too late).

Once you have a big package poisoned like this, all you can basically  
do is monkey-patch absolute_url() which is what I had to do on several  
occasions.

So by my definition, the URL (relative or not) should *always* include  
eventual _vh_xyz parts. If what one really needs is related to the  
physical layout of the ZODB, there is always getPhysicalPath().

URLs are in fact just some whack attributes of objects, and objects can  
have more than one URL at any time, depending on Vhost configs *only*.  
URLs are a function of the current REQUEST (traversal) and do represent  
little information with regard to an object's location in the ZODB.

I see the main issue here in that the concepts of URL and physical  
location are not well separated (CMF's getIcon() attempting to use URLs  
to locate objects for example).

Should this be your last word on this I am with Lennart in that we have  
to think about a whole new class of API methods for URL information.

Regards,
Stefan
P.S.: I have written a bunch of regression tests for absolute_url  
behavior over the weekend and if nobody tells me otherwise am going to  
check them into Products/SiteAccess/tests.



On Montag, Dez 8, 2003, at 07:53 Europe/Vienna, Evan Simpson wrote:

Yuppie wrote:
Yes. getIcon() is the cause of the problem I see:
To access the ZMI I use this Apache rule:
ProxyPass /zope27  
http://localhost:8080/VirtualHostBase/http/example.org:80/ 
VirtualHostRoot/_vh_zope27 getIcon() for a folder in myCMFSite  
returns 'zope27/myCMFSite/folder_icon.gif'
(was 'myCMFSite/folder_icon.gif' in Zope 2.6)
OFS/dtml/main.dtml adds BASEPATH1, so the URL is  
'/zope27/zope27/myCMFSite/folder_icon.gif'
(would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6)
Based on this, and on a lot of back-burner pondering, I'm now thinking  
that the proper fix for this is the one you suggest.  It makes sense  
for the relative version of the absolute path to omit BASE1, the URL  
of the virtual root, returning the semantics of absolute_path(1) to  
"path relative to the virtual root".  Use cases that need a  
hostname-relative URL can use BASEPATH1 + absolute_url(1).

Cheers,

Evan @ 4-am
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is.   /Pete McBreen/
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Evan Simpson]

Yuppie wrote:
Yes. getIcon() is the cause of the problem I see:

To access the ZMI I use this Apache rule:
ProxyPass /zope27 
http://localhost:8080/VirtualHostBase/http/example.org:80/VirtualHostRoot/_vh_zope27 

getIcon() for a folder in myCMFSite returns 
'zope27/myCMFSite/folder_icon.gif'
(was 'myCMFSite/folder_icon.gif' in Zope 2.6)

OFS/dtml/main.dtml adds BASEPATH1, so the URL is 
'/zope27/zope27/myCMFSite/folder_icon.gif'
(would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6)
Based on this, and on a lot of back-burner pondering, I'm now thinking 
that the proper fix for this is the one you suggest.  It makes sense for 
the relative version of the absolute path to omit BASE1, the URL of the 
virtual root, returning the semantics of absolute_path(1) to "path 
relative to the virtual root".  Use cases that need a hostname-relative 
URL can use BASEPATH1 + absolute_url(1).

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi Evan!

Evan Simpson wrote:
Gotcha.  Grepping Zope's source and the Products I had to hand showed 
only one use of absolute_url(1), in Draft.py, so I hoped that making the 
implementation sane wouldn't affect too much.

Looking at the 1.4 branch of CMF, I see it in three places:

1. DiscussionTool.py uses it when looking up replies.  This looks like a 
non-issue for new or properly converted discussions in 1.4.

2. SkinsTool.py uses it to construct skin cookies.

3. Any caller of URLTool that passes 'relative=1' to it.  I can only 
find one of these, namely getIcon() in DynamicType.py.

Is #3 likely to be the cause of the problem you're seeing?  Can you be 
more specific about the circumstances of the problem?
Yes. getIcon() is the cause of the problem I see:

To access the ZMI I use this Apache rule:
ProxyPass /zope27 
http://localhost:8080/VirtualHostBase/http/example.org:80/VirtualHostRoot/_vh_zope27

getIcon() for a folder in myCMFSite returns 
'zope27/myCMFSite/folder_icon.gif'
(was 'myCMFSite/folder_icon.gif' in Zope 2.6)

OFS/dtml/main.dtml adds BASEPATH1, so the URL is 
'/zope27/zope27/myCMFSite/folder_icon.gif'
(would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6)

Zope doesn't know anything about the name 'zope27' and returns 'Resource 
not found'.

The icon URLs are also broken inside the CMF interface, so we would need 
a CMF 1.4.3 release to get this working with Zope 2.7.

Grepping the products on my disk I found some files using 
absolute_url(1), especially in CMFDeployment. I have no idea if your 
change fixes or breaks these products.

Please let me know if you need further information.

Cheers,
Yuppie


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Evan Simpson]

Yuppie wrote:
You introduced that concept in Zope 2.7. The method docstring is part of 
your change. Before Zope 2.7, absolute_url was defined different, worked 
different and was used different in products maintained by ZC.
[snip]
I don't think the old API was better. I'm just saying that you changed 
the API in a way that is not backwards compatible. I encountered the 
problem with a plain new CMF Site.
Gotcha.  Grepping Zope's source and the Products I had to hand showed 
only one use of absolute_url(1), in Draft.py, so I hoped that making the 
implementation sane wouldn't affect too much.

Looking at the 1.4 branch of CMF, I see it in three places:

1. DiscussionTool.py uses it when looking up replies.  This looks like a 
non-issue for new or properly converted discussions in 1.4.

2. SkinsTool.py uses it to construct skin cookies.

3. Any caller of URLTool that passes 'relative=1' to it.  I can only 
find one of these, namely getIcon() in DynamicType.py.

Is #3 likely to be the cause of the problem you're seeing?  Can you be 
more specific about the circumstances of the problem?

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi Evan!

Evan Simpson wrote:
Yuppie wrote:
 > 'relative to site object' is quoted from the API documentation of
 > absolute_url()
The API documentation is incorrect, and the docstring in the method is 
correct:

 '''Return a canonical URL for this object based on its
physical containment path, possibly modified by virtual hosting.
If the optional 'relative' argument is true, only return the
path portion of the URL.'''
"Relative" in this context refers to the concept of a "relative path" as 
used in rfc1808, not to a relationship with a Zope object.  It is meant 
for use in situations such as redirection to a secure page from an 
insecure one (eg. 'https://example.com' + target.absolute_url(1)) where 
you would otherwise have to generate the complete URL and then break it 
apart.
You introduced that concept in Zope 2.7. The method docstring is part of 
your change. Before Zope 2.7, absolute_url was defined different, worked 
different and was used different in products maintained by ZC.

Current behavior looks like this:

http://localhost:8080/temp_folder/test
absolute_url( ): http://localhost:8180/temp_folder/test
absolute_url(1): temp_folder/test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test 

absolute_url( ): http://www.example.com/temp_folder/test
absolute_url(1): temp_folder/test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test 

absolute_url( ): http://www.example.com/test
absolute_url(1): test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test 

absolute_url( ): http://www.example.com/foo/test
absolute_url(1): foo/test
This is entirely consistent, predictable, and easy to explain.  The 
problem you are encountering is almost certainly due to a use of 
absolute_url where it shouldn't be used, or is used incorrectly.
I don't think the old API was better. I'm just saying that you changed 
the API in a way that is not backwards compatible. I encountered the 
problem with a plain new CMF Site. And the use of absolute_url is 
consistent with Zope 2.6 API and implementation. So I don't think it's a 
problem of incorrect use.

Cheers,
Yuppie


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Lennart Regebro]

From: "Yuppie" <[EMAIL PROTECTED]>
> Quick?

Yeah, yeah. I was fast once I actually did it. :-)

> Please be careful with method names that might already be in use in some
> products. Google says Silva uses a getVirtualRoot() method.

And EasyPublisher uses all of these already.

>Why not  using REQUEST variables?

Because it would be wrong, ugly, inconsistent with GetPhysicalPath and/or
complicated to implement? :-)

To explain them I'll use Evans examples (without testing so I could be
wrong):

http://localhost:8080/temp_folder/test
getVirtualRoot(): ('',)
getVirtualPath(): ('', 'temp_folder', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')

http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test
getVirtualRoot(): ('',)
getVirtualPath(): ('', 'temp_folder', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')

http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test
getVirtualRoot(): ('', 'temp_folder')
getVirtualPath(): ('', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')

http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test
getVirtualRoot(): ('', 'temp_folder')
getVirtualPath(): ('', 'test')
getPhysicalPath(): ('', 'temp_folder', 'test')

I think :-)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

[Lennart Regebro]

From: "Clemens Robbenhaar" <[EMAIL PROTECTED]>
>  > Please be careful with method names that might already be in use in
some
>  > products. Google says Silva uses a getVirtualRoot() method.
>
>  ... which is defined in an "adapter"-style class which is not
> implementing Traversable itself, so there is no conflict here.
>
>  But thanks for checking this, anyway. :)

And even if it was, your implementation would reasonably override
Traversable, and there would be no breakage...



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Evan Simpson]

Lennart Regebro wrote:
I will check this into head this evening, and unless people scream tomorrow
I will check it into the 2.7 branch.
Please hold off.  I've been meaning to revisit this for a while, and I 
have a bit of time to do so today and tomorrow.  Also, virtual hosting 
is properly the domain of the request object, not the object being 
traversed.  This is why the modified absolute_url() uses 
REQUEST.physicalPathToURL.

Yuppie wrote:
> 'relative to site object' is quoted from the API documentation of
> absolute_url()
The API documentation is incorrect, and the docstring in the method is 
correct:

 '''Return a canonical URL for this object based on its
physical containment path, possibly modified by virtual hosting.
If the optional 'relative' argument is true, only return the
path portion of the URL.'''
"Relative" in this context refers to the concept of a "relative path" as 
used in rfc1808, not to a relationship with a Zope object.  It is meant 
for use in situations such as redirection to a secure page from an 
insecure one (eg. 'https://example.com' + target.absolute_url(1)) where 
you would otherwise have to generate the complete URL and then break it 
apart.

Current behavior looks like this:

http://localhost:8080/temp_folder/test
absolute_url( ): http://localhost:8180/temp_folder/test
absolute_url(1): temp_folder/test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test
absolute_url( ): http://www.example.com/temp_folder/test
absolute_url(1): temp_folder/test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test
absolute_url( ): http://www.example.com/test
absolute_url(1): test
http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test
absolute_url( ): http://www.example.com/foo/test
absolute_url(1): foo/test
This is entirely consistent, predictable, and easy to explain.  The 
problem you are encountering is almost certainly due to a use of 
absolute_url where it shouldn't be used, or is used incorrectly.

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Clemens Robbenhaar]

 [...]
 > Please be careful with method names that might already be in use in some 
 > products. Google says Silva uses a getVirtualRoot() method. Why not 
 > using REQUEST variables?

 ... which is defined in an "adapter"-style class which is not
implementing Traversable itself, so there is no conflict here.

 But thanks for checking this, anyway. :)

Cheers,
Clemens

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi Lennart!

Lennart Regebro wrote:

def getVirtualRoot(self):
[...]
def getVirtualPath(self):
How are these related to URLPATHn, BASEPATHn? I'm to lazy to figure it 
out myself;)

Quick, brutal, efficient, and usually dead wrong. That's me. :-)

//Lennart
Quick?

Please be careful with method names that might already be in use in some 
products. Google says Silva uses a getVirtualRoot() method. Why not 
using REQUEST variables?

Cheers,
Yuppie




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi Stefan!

Stefan H. Holek wrote:
No, no and 3 times no! The fix was done by Evan and is CORRECT. 
absolute_url () does not (and should not!) know anything about CMF or 
portals or whatever else!
'relative to site object' is quoted from the API documentation of 
absolute_url(), see 
.

'site object' in this context is the Zope application object and has 
nothing to do with a CMF Site or whatever else.

It MUST however return correct results in all possible VH situations and 
this is what the fix addresses.
Yes. But the correct result is what the API documentation defines. To 
get what you want you have to add BASEPATH1 defined as "the externally 
visible path to the root Zope folder" alias 'Zope application object' 
alias 'site object'. Look for example at OFS/dtml/main.dtml

The real problem is - and this is stated in the original report - that 
absolute_url(1) did return WRONG RESULTS when inside-out vhosting was in 
use. This has bitten me on several occasions when customers deployed 
their sites with the CMF portal NOT living in the root of the vhost (as 
opposed to the root of Zope) and SERIOUS breakage occurred all over 
their sites.
That's exactly the scenario where I discovered the API change. But it 
didn't fix anything, it broke at least the icon paths.

Cheers,
Yuppie


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Chris McDonough wrote:
On Wed, 2003-12-03 at 07:33, Yuppie wrote:
But is it worth to have a CMF 1.4.3 release just to fix this issue?


Probably not, at least if your Zope checkin mentions the reason for the
capabilities test and the deprecation warning and maybe the earliest
date after which the capabilities check could be removed.  It would be
good to put this in the code itself, so we know why the capabilities
check exists next year when reading the code... does that make sense to
you?
Sounds good. I'll make the Zope checkin regarding this issue within the 
next days.

Yuppie



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Chris McDonough]

On Wed, 2003-12-03 at 07:33, Yuppie wrote:

> Why can't the capabilities check go away in a future release? We could 
> add a deprecation warning in reindexIndex in case it detects the old 
> API.

That's true.

>  And of course CMF has to implement the new API. This is on the todo 
> list: 
> 
> But is it worth to have a CMF 1.4.3 release just to fix this issue?

Probably not, at least if your Zope checkin mentions the reason for the
capabilities test and the deprecation warning and maybe the earliest
date after which the capabilities check could be removed.  It would be
good to put this in the code itself, so we know why the capabilities
check exists next year when reading the code... does that make sense to
you?

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Yuppie]

Hi!

Chris McDonough wrote:
Eep.  Maybe CMF's overridden catalog should just be given a reindexIndex
method instead of doing a capability check in Zope?  More broadly, is it
worth embedding the capabilities check (which can never, ever go away)
into Zope itself or would it be better to change CMF to deal with the
API change?
Why can't the capabilities check go away in a future release? We could 
add a deprecation warning in reindexIndex in case it detects the old 
API. And of course CMF has to implement the new API. This is on the todo 
list: 

But is it worth to have a CMF 1.4.3 release just to fix this issue?

Cheers,
Yuppie


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Chris McDonough]

Eep.  Maybe CMF's overridden catalog should just be given a reindexIndex
method instead of doing a capability check in Zope?  More broadly, is it
worth embedding the capabilities check (which can never, ever go away)
into Zope itself or would it be better to change CMF to deal with the
API change?

On Wed, 2003-12-03 at 06:53, Yuppie wrote:
> Hi!
> 
> 
> Migrating a CMF Site from Zope 2.6 to Zope 2.7.0 b3, I stumbled over 
> these two Zope 2.7 issues:
> 
> 
> 1.) absolute_url(relative=1) behaves different
> --
> 
> 'relative' was changed from 'relative to site object' to 'relative to 
> server root'. This is an API change and breaks Products like CMF.
> 
> See 
> 
> I propose to revert this change.
> 
> 
> 2.) reindexIndex not 100% backwards compatible
> --
> 
> CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. 
> Zope's reindexIndex fails because CMF doesn't implement the new 
> catalog_object API.
> 
> See 
> 
> I propose to add a capability check in reindexIndex.
> 
> 
> I'd volunteer to fix these issues in CVS as proposed, but maybe the 
> people who made these changes still feel responsible for their code or 
> there are objections regarding the proposed fixes.
> 
> Any feedback is welcome.
> 
> 
> Cheers,
>   Yuppie
> 
> 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )