[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/