Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions
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 dtml-var BASEPATH1/dtml-var absolute_url(1) 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
Toby Dickenson wrote: Because dtml-var BASEPATH1/dtml-var absolute_url(1) looks nicer than without the slash ? OT: Seeing as that would actually have to be written dtml-var REQUEST.BASEPATH1 html_quote/dtml-var absolute_url(1) html_quote 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
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 )
Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions
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
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
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: pTypical relative path using absolute_url(1): span tal:replace=python:'/' + here.absolute_url(1) / /p pBASEPATH1 is: span tal:replace=request/BASEPATH1 / /p pBetter relative path using BASEPATH1 and absolute_url(1): span tal:replace=python:request['BASEPATH1']+here.absolute_url(1) / /p 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
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 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
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
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
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
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
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 )