Hello, the following code <dtml-with subfolder> <A HREF="<dtml-var absolute_url>"><dtml-var title_or_id></A> </dtml-with> Will result in <A HREF="/subfolder">Subfolder title</A> Correct would be <A HREF="/subfolder/">Subfolder title</A> (Note the second "/"). Why is it missing? So long Ulli -- ----------------- Die Website Effizienzer ------------------ luna-park Bravo Sanchez, Vollmert, Wisser GbR Ulrich Wisser mailto:u.wisser@luna-park.de Alter Schlachthof, Immenburgstr. 20 Tel +49-228-9654055 D-53121 Bonn Fax +49-228-9654057 ------------------http://www.luna-park.de ------------------
Ulrich Wisser wrote:
<A HREF="/subfolder">Subfolder title</A>
Correct would be
<A HREF="/subfolder/">Subfolder title</A>
(Note the second "/").
I agree with this but I'm not sure on what the protocols say. All I know is that I've had trouble with cookies on occasion with Zope and IE when the second / is omitted. Not problems with Netscape though... Are URLs which end wit ha folder supposed to end in a / ie: http://my.site/folder/ What is the correct course of action for a Web server when it encounters as URL that points to a folder but doesn't end in a /? ie: request for http://my.site/folder Someone a while back suggested a redirect to http://my.site/folder/ Is this correct? What is Zope supposed to do and what does it acutally do? ;-) cheers, Chris
Chris Withers wrote:
I agree with this but I'm not sure on what the protocols say. All I know is that I've had trouble with cookies on occasion with Zope and IE when the second / is omitted. Not problems with Netscape though...
Are URLs which end wit ha folder supposed to end in a / ie: http://my.site/folder/
What is the correct course of action for a Web server when it encounters as URL that points to a folder but doesn't end in a /? ie: request for http://my.site/folder
Someone a while back suggested a redirect to http://my.site/folder/ Is this correct?
This is what most filestore-based web servers do.
What is Zope supposed to do and what does it acutally do? ;-)
Zope is an Object Publishing Environment, so the conventions for files don't necessarily apply. One route is to say that any object that may have sub-objects shall be refered to by "url/", and any requests to "url" shall be redirected to "url/". I don't like this, though. The nature of acquisition is that any object's URL can quite validly have other stuff appended to the end of it. The main difference is that web browsers will treat relative URLs differently. For example, consider the link <a href="foo">, and the zope folder http://server.com/granny/mother/dauthter. If the browser thinks the URL is http://server.com/granny/mother/daughter then the resolved link will be http://server.com/granny/mother/foo But, if the browser things the URL is http://server.com/granny/mother/daughter/ the resolved link will be to a subobject of daughter http://server.com/granny/mother/daughter/foo Zope gets around this by doing clever things with the <base href="stuff"> tag. Take a look at http://www.zope.org/SiteIndex The URL does not cause the browser to redirect to SiteIndex/, but the base tag in the page is <base href="http://www.zope.org/SiteIndex/"> Perhaps the problems Chris has observed with IE stem from IE not using the base tag in its cookie algorithms? -- Steve Alexander Software Engineer Cat-Box limited
Steve Alexander wrote: [snip]
Zope gets around this by doing clever things with the <base href="stuff"> tag.
Take a look at http://www.zope.org/SiteIndex
Cheers for the excellent explanation, Steve :-) This is the reason why the <!--</head>--> hack which some people use when virtual hosting on Zope is BAD(tm) It does make running a web-wacker over a Zope site a bti of a pain though...
Perhaps the problems Chris has observed with IE stem from IE not using the base tag in its cookie algorithms?
Hmmm... could be so, can anyone else provide some evidence? It might just be something else that I was doign wrong... cheers, Chris
Hi!
This is what most filestore-based web servers do.
What is Zope supposed to do and what does it acutally do? ;-)
Zope is an Object Publishing Environment, so the conventions for files don't necessarily apply.
One route is to say that any object that may have sub-objects shall be refered to by "url/", and any requests to "url" shall be redirected to "url/".
Nevertheless the missing / are the problem why tools like wget or pavuk for mirroring Zope sites are not working.. They create files when getting url and when trying to download url/stuff then stuff cannot be created. -- christian
Christian Scholz wrote:
Steve Alexander wrote:
Zope is an Object Publishing Environment, so the conventions for files don't necessarily apply.
One route is to say that any object that may have sub-objects shall be refered to by "url/", and any requests to "url" shall be redirected to "url/".
Nevertheless the missing / are the problem why tools like wget or pavuk for mirroring Zope sites are not working.. They create files when getting url and when trying to download url/stuff then stuff cannot be created.
The programs wget and pavuk use heuristics to decide how best to map the namespace and data available on the web server through URLs onto a local filesystem. Most web servers make their internal filesystem available to the rest of the internet via HTTP. Zope's internal structure is very much more complex than a simple filesystem. Therefore, the mapping of what is inside the server to a filesystem is incomplete. I don't think Zope should endeavour to look more like a filesystem; I think the tools we use to interact with web sites need more tunable heuristics. Perhaps the best sort of tool for taking a "snapshot" of a Zope instance would be a Zope Product that is given a root URL, and returns a .tar.gz of the directory structure and files in that snapshot. Otherwise, why not patch wget or pavuk so that they treat everything as a potential folder, with the data in an index.html file? You could then run a second pass program to simplify any folders that only contain index.html into just a file. -- Steve Alexander Software Engineer Cat-Box limited
Hi!
Christian Scholz wrote:
Steve Alexander wrote:
Zope is an Object Publishing Environment, so the conventions for files don't necessarily apply.
One route is to say that any object that may have sub-objects shall be refered to by "url/", and any requests to "url" shall be redirected to "url/".
Nevertheless the missing / are the problem why tools like wget or pavuk for mirroring Zope sites are not working.. They create files when getting url and when trying to download url/stuff then stuff cannot be created.
The programs wget and pavuk use heuristics to decide how best to map the namespace and data available on the web server through URLs onto a local filesystem.
Most web servers make their internal filesystem available to the rest of the internet via HTTP. Zope's internal structure is very much more complex than a simple filesystem. Therefore, the mapping of what is inside the server to a filesystem is incomplete. I don't think Zope should endeavour to look more like a filesystem; I think the tools we use to interact with web sites need more tunable heuristics.
Perhaps the best sort of tool for taking a "snapshot" of a Zope instance would be a Zope Product that is given a root URL, and returns a .tar.gz of the directory structure and files in that snapshot.
Otherwise, why not patch wget or pavuk so that they treat everything as a potential folder, with the data in an index.html file? You could then run a second pass program to simplify any folders that only contain index.html into just a file.
Sure, this would work for me but not for any other visitors to my site who e.g. want to mirror some documentation instead of being online all the time.. I don't see this as best solution.. cheers, Christian
Steve Alexander wrote:
Perhaps the best sort of tool for taking a "snapshot" of a Zope instance would be a Zope Product that is given a root URL, and returns a .tar.gz of the directory structure and files in that snapshot.
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz. I wish I had time to do it myself. It would be pretty easy. But now I have other projects I need to do... any takers? Shane
Shane Hathaway wrote:
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz.
What's the difference between a "static snapsnot" and a normal "export" ? cheers, Chris
Chris Withers wrote:
Shane Hathaway wrote:
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz.
What's the difference between a "static snapsnot" and a normal "export" ?
Zope currently exports a big collection of Python objects, including security information, attributes, and a lot of other things. The only way to read this file is to use Zope. It is intended to make it possible to precisely reconstitute a set of objects. A static snapshot would be a collection of HTML and graphics files, intended to be served up by a simple web server. It would not be useful to try to re-import this kind of file back into Zope; all of the metadata would be lost. Its usefulness would be the fact that, using a server such as Apache, the pages could be served at a rate of thousands of hits per second. Shane
Shane Hathaway writes: Sounds like a 'rendered' export. Could you run it though the ZPublisher into a compression agent?
Chris Withers wrote:
Shane Hathaway wrote:
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz.
What's the difference between a "static snapsnot" and a normal "export" ?
Zope currently exports a big collection of Python objects, including security information, attributes, and a lot of other things. The only way to read this file is to use Zope. It is intended to make it possible to precisely reconstitute a set of objects.
A static snapshot would be a collection of HTML and graphics files, intended to be served up by a simple web server. It would not be useful to try to re-import this kind of file back into Zope; all of the metadata would be lost. Its usefulness would be the fact that, using a server such as Apache, the pages could be served at a rate of thousands of hits per second.
Shane
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Chris Withers wrote:
Shane Hathaway wrote:
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz.
What's the difference between a "static snapsnot" and a normal "export" ?
The snapshot would call methods, and save their returned rendered values under that filename. Export saves the DTML in the methods. -- Steve Alexander Software Engineer Cat-Box limited
Hi! On Tue, May 16, 2000 at 09:44:49AM -0400, Shane Hathaway wrote:
Steve Alexander wrote:
Perhaps the best sort of tool for taking a "snapshot" of a Zope instance would be a Zope Product that is given a root URL, and returns a .tar.gz of the directory structure and files in that snapshot.
That's an excellent suggestion that could be taken a little further: make "static snapshot" a new option on the "export" screen. It would simply create a .tar.gz.
Then again only admin users would have the possibility to make a snapshot. Unfortunately this will not solve the wget/pavuk-Problem if mirroring.. (and thus Zope site are not able to be mirrored). I will think about this a little more and if it can't be really solved with BASE tags or whatever.. (at least I will do when I am back from hospital in 2 days.. ;-) cheers, Christian
Hello Steve, thanks for your explanation. But I disagree at some point: The folder object has its own acl_user and there for can authorize its own users who are not authorized on any object which are not located under the folder. I came to this problem with this error: http://my.zope/ <- accessable by anonymous http://my.zope/cssGlobal <- accessable by anonymous http://my.zope/subfolder <- only user u.wisser can view this folder But when Zope wants a authorisation for this object my browser (IE and Mozilla) will send the authorisation for every object in that path (which is "/"). Now the browser will send auth information to access cssGlobal. That will fail because the user u.wisser does not exist in that context. The authorisation should be made for http://my.zope/subfolder/. Then the path is /subfolder/ and only objects under subfolder will be accessed with auth info. Yes I use basic authentication (no cookies). So long Ulli -- ----------------- Die Website Effizienzer ------------------ luna-park Bravo Sanchez, Vollmert, Wisser GbR Ulrich Wisser mailto:u.wisser@luna-park.de Alter Schlachthof, Immenburgstr. 20 Tel +49-228-9654055 D-53121 Bonn Fax +49-228-9654057 ------------------http://www.luna-park.de ------------------
Ulrich Wisser wrote:
The authorisation should be made for http://my.zope/subfolder/. Then the path is /subfolder/ and only objects under subfolder will be accessed with auth info.
Yes I use basic authentication (no cookies).
This is really interesting. :-) I haven't had a chance to look into this yet, but from what you've said, the default basic authentication algorithm in Zope is to use as the "authentication root" the value of PATH_INFO (or PATH_TRANSLATED perhaps), when it should be set to the value of "root" in the following pseudocode. if PATH_ENFO ends in '/': root = PATH_INFO else: root = PATH_INFO+'/'. That sounds like it is probably a simple patch to Zope authentication. -- Steve Alexander Software Engineer Cat-Box limited
Steve Alexander wrote:
This is really interesting. :-)
[snip stuff I didn't really understand]
That sounds like it is probably a simple patch to Zope authentication.
That would be nice :-) I think I posted this exact same problem to both the Zope and Zope-Dev lists (at seperate times ;-) in March and got no reply to either posting. See: http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/82AE22A20C7E88AE If anyone could fix this so it works logically, I'd be really happy :-) cheers, Chris
participants (7)
-
Chris Withers -
cs＠comlounge.net -
Jason Spisak -
Shane Hathaway -
Steve Alexander -
Steve Alexander -
Ulrich Wisser