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