Dieter Maurer <dieter@handshake.de> wrote, in part:
A trivial URL reference is one not containing a "/". They are harmless. A relative URL reference containing a "/" is non-trivial unless the path segment before each "/" is either "." or "..". Non-trivial URL references can cause growing URLs. Do not use them.
I'm a beginner. I have a very simple site in which the menu is generated with the following code: <dtml-with OSPN> <dtml-in "objectItems(['Folder'])" sort="id"> <dtml-if expr="id[0] in '0123456789'"> <a href="&dtml-id;"><dtml-var expr="id[2:].replace('_', ' ')"></a><br/> </dtml-if> </dtml-in> </dtml-with> Each time one clicks on a menu item the corresponding page is displayed. There appears to be no non-trivial URL reference. owever, the URL grows. Would you please point out my mistake. Thanks very much. Bill
On Thu, May 15, 2003 at 10:46:34AM -0400, Bill Bell wrote:
Dieter Maurer <dieter@handshake.de> wrote, in part:
A trivial URL reference is one not containing a "/". They are harmless. A relative URL reference containing a "/" is non-trivial unless the path segment before each "/" is either "." or "..". Non-trivial URL references can cause growing URLs. Do not use them.
I'm a beginner. I have a very simple site in which the menu is generated with the following code:
<dtml-with OSPN> <dtml-in "objectItems(['Folder'])" sort="id"> <dtml-if expr="id[0] in '0123456789'"> <a href="&dtml-id;"><dtml-var expr="id[2:].replace('_', ' ')"></a><br/> </dtml-if> </dtml-in> </dtml-with>
Each time one clicks on a menu item the corresponding page is displayed. There appears to be no non-trivial URL reference. owever, the URL grows.
I'm afraid Dieter's wrong about this. yes, it can happen! :-) Use an absolute url for the link: <a href="&dtml-absolute_url;"><dtml-var expr="id[2:].replace('_', ' ')"></a><br/> -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
Bill Bell wrote at 2003-5-15 10:46 -0400:
Dieter Maurer <dieter@handshake.de> wrote, in part:
A trivial URL reference is one not containing a "/". They are harmless. A relative URL reference containing a "/" is non-trivial unless the path segment before each "/" is either "." or "..". Non-trivial URL references can cause growing URLs. Do not use them.
I'm a beginner. I have a very simple site in which the menu is generated with the following code:
<dtml-with OSPN> <dtml-in "objectItems(['Folder'])" sort="id"> <dtml-if expr="id[0] in '0123456789'"> <a href="&dtml-id;"><dtml-var expr="id[2:].replace('_', ' ')"></a><br/> </dtml-if> </dtml-in> </dtml-with>
Each time one clicks on a menu item the corresponding page is displayed. There appears to be no non-trivial URL reference. owever, the URL grows.
You must look at the HTML source of your page (ask your browser for the page source). When it does not contain complex relative URLs, then the URLs should not grow. If this is wrong, please post the HTML source. Dieter
On Thu, May 15, 2003 at 09:13:00PM +0200, Dieter Maurer wrote:
When it does not contain complex relative URLs, then the URLs should not grow.
If this is wrong, please post the HTML source.
i'm afraid it is wrong. I already posted a trivial example. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
On Thu, 2003-05-15 at 10:19, Paul Winkler wrote:
On Thu, May 15, 2003 at 09:13:00PM +0200, Dieter Maurer wrote:
When it does not contain complex relative URLs, then the URLs should not grow.
If this is wrong, please post the HTML source.
i'm afraid it is wrong. I already posted a trivial example.
Indeed you did. Ultimately Dieter's right, though he wasn't being very clear. A "trivial" URL *should* contain ../ when it references URLs above the current document. If you don't use that, you're *requesting* the higher folder in the context of the lower one... Zope can hardly be blamed for giving you what you ask for. Use ../ for upward-bound URLs and everything should work out fine. Or you could always stick to absolute URLs... those are always safe. FWIW, Dylan
On Thu, May 15, 2003 at 03:29:55PM -0700, Dylan Reinhardt wrote:
On Thu, 2003-05-15 at 10:19, Paul Winkler wrote:
On Thu, May 15, 2003 at 09:13:00PM +0200, Dieter Maurer wrote:
When it does not contain complex relative URLs, then the URLs should not grow.
If this is wrong, please post the HTML source.
i'm afraid it is wrong. I already posted a trivial example.
Indeed you did.
and it wasn't even the example i meant to give :( sorry for muddling the issue further. given two *parallel* folders, A and B (not B within A as I stated), each containing an index_html; /A/index_html contains a link <a href="B"> link to B</a> /B/index_html contains a link <a href="A"> link to A</a> This arrangement will also create the ever-growing URLs. And it's easy to create this situation by accident. Just put the links in a standard_html_header or a standard_template and use it in both index_html's.
Ultimately Dieter's right, though he wasn't being very clear.
ah, i see. yes, that was not very clear. by itself, the statement
A trivial URL reference is one not containing a "/". They are harmless.
... is not really true, as I've shown. But the next statement, which qualifies the first, is true:
A relative URL reference containing a "/" is non-trivial unless the path segment before each "/" is either "." or "..".
A "trivial" URL *should* contain ../ when it references URLs above the current document.
If you don't use that, you're *requesting* the higher folder in the context of the lower one... Zope can hardly be blamed for giving you what you ask for.
Nice explanation, thanks. The ../foo idiom works fine with the example I gave above.
Use ../ for upward-bound URLs and everything should work out fine. Or you could always stick to absolute URLs... those are always safe.
And it's easy to get Zope to generate absolute URLs for us. This has the additional benefit of improving the ability of browsers* to cache your zope content, as the "../foo" idiom is not guaranteed to always yield the same normalized path once acquisition comes into play. This is why i recommend only using absolute URLs in navigational templates, e.g. the typical standard_html_header or a CMF main_template. * probably cacheing proxies like squid too, although i have not done this myself. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
On Thu, 2003-05-15 at 16:30, Paul Winkler wrote:
given two *parallel* folders, A and B (not B within A as I stated), each containing an index_html; /A/index_html contains a link <a href="B"> link to B</a>
/B/index_html contains a link <a href="A"> link to A</a>
This arrangement will also create the ever-growing URLs. And it's easy to create this situation by accident. Just put the links in a standard_html_header or a standard_template and use it in both index_html's.
Actually, this is just a specific case of the issue identified with your other example. It arises because of a distinction made by most browsers that isn't observed by Zope. Let's take an obvious case. Assume these two URLs: http://server/path/A/foo.htm http://server/path/B/bar.htm Any links in foo.htm that are expressed "trivially" are expressed in relation to: http://server/path/A/ Thus, if a link in foo is of the form <a href=B>, the request generated **by the browser** is: http://server/path/A/B When Zope is handed this request, it will dutifully acquire B in the context of A. Many other web servers would just kick back a 404. Since you *really* want to be linking in reference to path/ the best form to use when linking a B object to an A object is: <a href=../B/obj_name> Now... to your specific index_html case. A and B are peers, but A's contents are not peers of B's contents. The fact that A and B are callable objects suggests that their index_html methods *should* be peers, but it's not necessarily the case. Sadly, how it works depends to some degree on the client... and we all know how consistent web clients can be. If you make a folder A with an index_html method that contains a "trivial" hyperlink, you can show (in certain browsers) that there is a difference between how the following URLs are handled: http://server/path/A http://server/path/A/ Links in the former are evaluated in reference to path/ and the latter are in reference to A/. In essence, the browser crafts all relative links in relation to the final slash. Thought of another way, the first displays A *as content* and the latter shows A *as a directory*. This distinction is meaningless within Zope, but holds tremendous importance to the browser. As you may already know, the inclusion of a trailing slash in a URL is a point of some inconsistency among widely-deployed browsers. All of which is a long way of saying that the problem is caused by a opportunity for inconsistency in how web browsers will treat relative links from the default indexes of Zope folders. I've only found this to be a problem running Zope standalone, however... running Apache in front provides an opportunity to handle the trailing slash issue and hand off consistent URLs to Zope. Anyway... those are mostly just observations. A more formal analysis that included testing of actual browser behavior would be interesting, but probably won't be forthcoming for some time. :-) As before, you can hardly go wrong with absolute URLs. When in doubt, go with the Zen of Python: "explicit is better than implicit". Dylan
On Fri, May 16, 2003 at 10:07:34AM -0700, Dylan Reinhardt wrote: (very nice explanations snipped)
All of which is a long way of saying that the problem is caused by a opportunity for inconsistency in how web browsers will treat relative links from the default indexes of Zope folders.
yes indeed. I have managed to do things in zope that worked in one browser, but only worked in another browser if i was very careful to use a trailing slash. I don't remember the details, but I do remember that diagnosing the problem was maddening.
As before, you can hardly go wrong with absolute URLs. When in doubt, go with the Zen of Python: "explicit is better than implicit".
it sure is :) -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
Dylan Reinhardt wrote at 2003-5-15 15:29 -0700:
On Thu, 2003-05-15 at 10:19, Paul Winkler wrote:
On Thu, May 15, 2003 at 09:13:00PM +0200, Dieter Maurer wrote:
When it does not contain complex relative URLs, then the URLs should not grow.
If this is wrong, please post the HTML source.
i'm afraid it is wrong. I already posted a trivial example.
Indeed you did.
Ultimately Dieter's right, though he wasn't being very clear.
Thank you for the defense. Unfortunately, I fear, Paul is right and I were wrong :-( The reason: Zope effectively turns some URLs of the form "url" into "url/index_html" turning trivial relative URLs effectively into non-trivial ones. Thank you, Paul, for the enlightenment! Dieter
On Fri, 2003-05-16 at 12:44, Dieter Maurer wrote:
Unfortunately, I fear, Paul is right and I were wrong :-(
The reason:
Zope effectively turns some URLs of the form "url" into "url/index_html" turning trivial relative URLs effectively into non-trivial ones.
As discussed in the follow-up to that message, I think it's a trailing-slash issue on the client side. Zope answers the request it receives... it's up to the client to formulate the question correctly, and it's not clear that there is any consistency with how folder-as-content requests *should* work.
From Zope's way of thinking, a request for a folder (with no trailing slash) is a request for content *at that folder's level*. But with that assumption, it follows that a link from the folder's index to that folder's contents would *need* to specify the folder itself. That's bizarre.
So it makes more sense that folders should be treated as folders, index methods should be treated as sub-objects of the folder and trailing slashes should be assumed and/or added to folder-terminated URLs. But since Zope doesn't generally render A and A/ any differently, there's little incentive to make and/or enforce such a rule. But subtle issues do arise for lack of a content/folder distinction. I don't agree you were wrong... just right with certain caveats. :-) Dylan
On 15 May 2003 at 21:13, Dieter Maurer wrote:
Bill Bell wrote at 2003-5-15 10:46 -0400:
I have a very simple site in which the menu is generated with the following code:
<dtml-with OSPN> <dtml-in "objectItems(['Folder'])" sort="id"> <dtml-if expr="id[0] in '0123456789'"> <a href="&dtml-id;"><dtml-var expr="id[2:].replace('_', ' ')"></a><br/> </dtml-if> </dtml-in> </dtml-with>
Each time one clicks on a menu item the corresponding page is displayed. There appears to be no non-trivial URL reference. owever, the URL grows.
You must look at the HTML source of your page (ask your browser for the page source).
When it does not contain complex relative URLs, then the URLs should not grow.
If this is wrong, please post the HTML source.
Here is the HTML. <html> <head> <base href="http://localhost:8080/OSPN/07Organisations_in_Your_Area/01Suicide_Prevent ion_Week/" /> <title></title> <style> * { font: normal 10pt Helvetica; } </style> </head> <body style="background-color: lightgrey; "> <div style="margin-left: 20px; width: 600px; "> <div style="margin-bottom: 20px; padding: 10px; width: 100%; text-align: center; background-color: white; font: bold 12pt; border: thin solid black; "> <span></span> <span style="font: bold 14pt; ">Suicide Prevention Week</span> - Ontario Suicide Prevention Network <br /><span style="font: bold 12pt cursive; ">- Promoting Networking -</span> </div> <div style="margin-right: 20px; width: 30%; float: left; border: thin solid black; background-color: white; padding: 10px; "> <div style="font: bold 12pt; margin-bottom: 10px; ">Welcome!</div> <span> <a href="01Suicide_Prevention_Week">Suicide Prevention Week</a><br/> <a href="02Upcoming_Events">Upcoming Events</a><br/> <a href="03News">News</a><br/> <a href="05Give_Us_Your_News">Give Us Your News</a><br/> <a href="06News_Received">News Received</a><br/> <a href="07Organisations_in_Your_Area">Organisations in Your Area</a><br/> <a href="08Suicide_Bereavement">Suicide Bereavement</a><br/> <a href="10Provincial_Advisors">Provincial Advisors</a><br/> <a href="20Board_of_Directors">Board of Directors</a><br/> <a href="50Background_and_History">Background and History</a><br/> <a href="70Membership_Information">Membership Information</a><br/> <a href="80Participating">Participating</a><br/> <a href="85Committees">Committees</a><br/> <a href="87Donating">Donating</a><br/> <a href="90Contacting_Us">Contacting Us</a><br/> <a href="95RSS_news_feed">RSS news feed</a><br/> <a href="99Search_this_website">Search this website</a><br/> </span> </div> <span><div style="padding: 10px; overflow: auto; background: white; width: 400px; height: 400px; font: normal 10pt Helvetica; position: absolute; top: 90px; "> Please feel free to download this <a href="SPWDoc">Suicide Prevention Week document.</a> </div></span> </div> </body> </html> Zope seems to be supplying the <base> tag as a friendly gesture. At least, it does not appear in any form in my code. What I have found, or seem to have found, is that if insert the following tag into my template the thing works ok. <base href="http://localhost:8080/OSPN/" /> Dieter, thanks very much for the tip. I would never have found this unaided. Bill
On Thu, May 15, 2003 at 04:58:21PM -0400, Bill Bell wrote:
Zope seems to be supplying the <base> tag as a friendly gesture. At least, it does not appear in any form in my code.
yes, it does that so relative links from some_folder/index_html will still work when you visit some_folder directly.
What I have found, or seem to have found, is that if insert the following tag into my template the thing works ok.
<base href="http://localhost:8080/OSPN/" />
ok, but you have to remember to keep it up to date if you move this stuff. did you not see the alternate solution I posted? use &dtml-absolute_url; instead of &dtml-id; in the link. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
participants (4)
-
Bill Bell -
Dieter Maurer -
Dylan Reinhardt -
Paul Winkler