I'm having a problem with LocalFS, HTML files, and the <base href> that gets added to pages. But I feel, at its source, Zope is just being nuts. HTTPResponse.insertBase inserts <base href> to pages; in turn, this base is set in HTTPResponse.setBase, where it ensures that the base always ends in "/". This causes paths to grow, as leaf pages (non-directory pages) get treated like directories. This is annoying in normal Zope objects, but LocalFS objects don't seem to acquire parents, so the extra elements in the URL that point to a LocalFS are just broken. While these growing URLs seem to be a persistent problem for many people in Zope, I assume there is a way that the paths *should* work. What do people do to get rid of these? Is there a way to keep HTTPResponse from adding a <base href> at all? (I could add "<!-- <base> -->" to pages to trick insertBase into thinking the tag has already been added, but that's obviously a bad hack) -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Ian Bicking wrote at 2003-11-25 12:33 -0600:
I'm having a problem with LocalFS, HTML files, and the <base href> that gets added to pages. But I feel, at its source, Zope is just being nuts.
HTTPResponse.insertBase inserts <base href> to pages; in turn, this base is set in HTTPResponse.setBase, where it ensures that the base always ends in "/". This causes paths to grow, as leaf pages (non-directory pages) get treated like directories. This is annoying in normal Zope objects, but LocalFS objects don't seem to acquire parents, so the extra elements in the URL that point to a LocalFS are just broken.
Many people do not like the Zope generated "base" tags. But, in fact, they are necessary in order for relative URL references to work. Zope *MUST* set the base tag whenever it implicitly modifies the URL. Otherwise, the base URL assumed by the browser is different from the real base URL of the request -- relative URL references will fail. The problem is not Zope's "base" tag. The problem are non-trivial relative URL references (an relative URL reference containing at most one "/" -- you must count implicit addition of "/index_html" done by Zope as well). To avoid incresing URLs you must avoid non-trivial URL references, either by strictly using absolute URLs or by using sufficiently many "../" in your relative URL references. -- Dieter
Hi Ian, please read my How-To on the <base /> tag. You really do not want to get rid of it. IT would ruin your Zope application almost certainly. http://zope.org/Members/wisser/HowTo.2003-09-29.2529 LocalFS objects are no real Zope objects. Thus they do not go through the Zope rendering engine. That said, it means it is your job to make all links work. Maybe you could send me an example, I might be able to help you with the links. Ulrich -- World Wide Web Publisher, Ulrich Wisser, Vallatorpsv.158, S-18752 Täby http://www.publisher.de Tel: +46-8-53460905 Fax: +46-8-534 609 06
On Nov 30, 2003, at 3:44 PM, Ulrich Wisser wrote:
LocalFS objects are no real Zope objects. Thus they do not go through the Zope rendering engine. That said, it means it is your job to make all links work.
This is the issue -- they do appear to go through the rendering engine (well, specifically HTTPResponse, which is where base href is added). LocalFS objects are translated into real Zope objects as well, at its simplest into File objects (but it can also be DTML objects or other classes, based on configuration). But that wouldn't really matter, as it's not File that is creating the base href. In this case we have some files on the disk that we want Zope to protect with a login. All the links in the files are relative. So we mount the files in /static, and access /static/visitors.html -- the base href is then set to "/static/visitors.html/", which is obviously incorrect (it should be simply "/static/", or preferably no base href at all). (Ultimately we've solved this by taking the files out of Zope, and using a CGI script to handle authentication) -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Ian Bicking wrote at 2003-11-30 17:10 -0600:
... In this case we have some files on the disk that we want Zope to protect with a login. All the links in the files are relative. So we mount the files in /static, and access /static/visitors.html -- the base href is then set to "/static/visitors.html/", which is obviously incorrect (it should be simply "/static/", or preferably no base href at all).
It is definitely not what you want and what you need for your application. But, it is unclear whether it is incorrect in general. An example that comes to mind: a self referencing file object containing an URL reference "<a href="manage_main">Management</a">. I think, it must reference the file object itself (the "base" tag ensures that) and not its container (would happen without "base" tag). If I had your problem, I would give "LocalFS" a variant of "File". It would rename "index_html" to "__call__" and then set "index_html = None". Result: no more magic URL enlargment and no "base" tag for these files. -- Dieter
participants (3)
-
Dieter Maurer -
Ian Bicking -
Ulrich Wisser