Hi all, I have tried Zope for a week and found a logic problem. An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think. People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so. Wei He
Hi, Wei He wrote:
An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think.
So do a lot of other people, but not for your reasons ;-)
People will be really confused to see such results:
http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images
Why would they see such URLs?
Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so.
If you're interested, take a look at Zope 3. However, in your case, you probably need to worry more about why you're generating URLs like the ones above rather than the fact that it is possible to do so. cheers, Chris
On Thu, 30 May 2002, Chris Withers wrote:
People will be really confused to see such results:
http://www.zope.org/Documentation/ZopeBook/Documentation http://www.zope.org/Images
Why would they see such URLs?
Normally would not. But if I know such a site is managed by Zope, I can easily find such a URL with dead loops. I don't know how search engines like Google handles this situation, at least it will cause unnecessary traffic to the site once a bad guy just simply publish the URL on their own page. I'm a little bit new to Zope. I don't yet have a lot of my own objects created under Zope. But I think there might be some objects like methods or scripts that is URL-sensitive. It will adds lots of tasks to the script itself to filter off unexpected request URLs to avoid generating errors that may turn into security holes.
Is there a way to setup an object to be uninheritable or as private to avoid this logic? Or maybe we should workout a way to do so.
If you're interested, take a look at Zope 3. However, in your case, you probably need to worry more about why you're generating URLs like the ones above rather than the fact that it is possible to do so.
Hackers everywhere. :) Wei He
From: "Wei He" <hewei@mail.ied.ac.cn>
An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think.
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
People will be really confused to see such results: http://www.zope.org/Documentation/ZopeBook/Documentation
Then don't show them these results. :-)
Whats confusing about that one?
I don't know how search engines like Google handles this situation,
Search engines follow links. Unless you display a looping link to them, they won't find it, and hence, it's not a problem. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB
Lennart Regebro wrote:
From: "Wei He" <hewei@mail.ied.ac.cn>
An object (say index_html) is inherited by child objects of the site say Document to make http://www.domain.com/Document share the upper level index_html. This sounds good but acutally not I think.
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
Well, I'm not so enthusiastic about it. Implicit acquisition in URLs leads to subtle bugs. One thing that just about every Zope site does is "acquire" images using a simple relative URL, but that makes the images much less cacheable. If "www.example.com/docs/tutorial/go.gif", "www.example.com/docs/go.gif", and "www.example.com/go.gif" refer to the same image, HTML authors are likely to just choose any of the three. The browser can't know they are the same image and will have to fetch the image up to three times. This problem explodes on larger sites unless you educate HTML authors. Another problem is illustrated by zope.org's version of ZWiki. I don't know if the problem is still there or whether it's in the main ZWiki product. ZWiki uses relative URLs, and some of the URLs displayed on the pages include a trailing slash and some don't. That leads to effective URLs that include doubled names. That's okay until a spider requests URLs like this: http://dev.zope.org/Wikis/DevSite/Proposals/Proposals/Proposals/FrontPage Looking at the zope.org logs, I once saw GoogleBot generate URLs like this to zope.org of 1000 characters or more. Shane
> Looking at the zope.org logs, I once saw GoogleBot generate URLs like > this to zope.org of 1000 characters or more. Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules. Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object... -- Andy McKay
On Thu, 30 May 2002, Andy McKay wrote:
> Looking at the zope.org logs, I once saw GoogleBot generate URLs like > this to zope.org of 1000 characters or more.
Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules.
Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object...
I just wonder whether it's possible to add an attribute, say 'inheritable', so that everyone will be happy. I think only then it can be called a 'feature'. Otherwise an obtrusion. Wei He
But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly. Any tool/language/approach/methodology can be used incorrectly, Rgds Tim On Fri, 2002-05-31 at 10:46, Wei He wrote:
On Thu, 30 May 2002, Andy McKay wrote:
> Looking at the zope.org logs, I once saw GoogleBot generate URLs like > this to zope.org of 1000 characters or more.
Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules.
Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object...
I just wonder whether it's possible to add an attribute, say 'inheritable', so that everyone will be happy.
I think only then it can be called a 'feature'. Otherwise an obtrusion.
Wei He
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Friday 31 May 2002 4:44 am, Tim Hoffman wrote:
But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly.
Agreed.
Any tool/language/approach/methodology can be used incorrectly,
But today implicit acquisition is forced onto almost every zope class, and every attribute lookup. Sometimes the way to use acquisition correctly is not to use it at all, but that is often an impossible option. These characteristics mean implicit acquisition is not a "tool" - its a disease. Imagine if you couldnt write a C++ class without including operator overloading functions......
Hi On Fri, 2002-05-31 at 15:14, Toby Dickenson wrote:
On Friday 31 May 2002 4:44 am, Tim Hoffman wrote:
But whilst you might think acquisition looks like inheritance it isn't Please don't confuse the two, they really are different, and until you think about them differently, I believe you won't necessarily grasp the significance of acquisition, or use it properly.
Agreed.
Any tool/language/approach/methodology can be used incorrectly,
But today implicit acquisition is forced onto almost every zope class, and every attribute lookup. Sometimes the way to use acquisition correctly is not to use it at all, but that is often an impossible option. These characteristics mean implicit acquisition is not a "tool" - its a disease.
True, however all of my work to date in CMF, I haven't found that acquisition, to be a major problem, except once. However the most problems I have had, are with poorly thought out or poorly documented object hierarchies, so that it is not obvious or clear where and when you should override methods, try "manage_afterClone" some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-) If how these things work and how to use them, was well documented , then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it. (I think we will be in a much better position with Zope 3) Also if it doesn't work the way it is documented you could call it a bug, whereas the current situation is hmm is this how it work or is it a bug, or am I missing something ;-) Rgds Tim
Imagine if you couldnt write a C++ class without including operator overloading functions...... I hate C++ ;-)
Tim Hoffman wrote:
However the most problems I have had, are with poorly thought out or poorly documented object hierarchies,
You mean "class hierarchies".
so that it is not obvious or clear where and when you should override methods, try "manage_afterClone" some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-)
You'll like Zope3 then. There is no dependency on class hierarchies. The inheritance hierarchies throughout are either very shallow or non-existent. However, none of the power of expressing the affordances of objects is lost. Instead, this is expressed through the interfaces an object implements, which can be definied either in your class definitions, or elsewhere in zcml or in other classes/interfaces.
If how these things work and how to use them, was well documented, then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it.
There is only so much complexity that I can handle at a time. Often working on what should be an isolated part of Zope2 exceeds that threshold.
(I think we will be in a much better position with Zope 3)
:-) -- Steve Alexander
Hi On Fri, 2002-05-31 at 16:10, Steve Alexander wrote:
Tim Hoffman wrote:
However the most problems I have had, are with poorly thought out or poorly documented object hierarchies,
You mean "class hierarchies".
Oops, yep, that's what I meant,
so that it is not obvious or clear where and when you should override methods, try "manage_afterClone" some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-)
You'll like Zope3 then. There is no dependency on class hierarchies. The inheritance hierarchies throughout are either very shallow or non-existent.
However, none of the power of expressing the affordances of objects is lost. Instead, this is expressed through the interfaces an object implements, which can be definied either in your class definitions, or elsewhere in zcml or in other classes/interfaces.
Yeah, I have been following most of the Zope3 discussions.
If how these things work and how to use them, was well documented, then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it.
There is only so much complexity that I can handle at a time. Often working on what should be an isolated part of Zope2 exceeds that threshold.
Tell me about it, I really can't do much without keeping an IDLE session going and trolling through all the source, try getting immutable unique ID's working for every object in a CMF site, that when you clone an object you get a new unique ID, man I had some trouble with that, it seemed where manage_afterClone changed in a release or two, so that things stopped working, after an upgrade. Having clearly defined public interfaces will certainly help. See ya T
(I think we will be in a much better position with Zope 3)
:-)
-- Steve Alexander
Hi all, Say you have 1_html with only one line: <dtml-var 2_html> When you HEAD http://xxx/1_html, you get Last-Modified refelecting only the last modification time of 1_html, while most people is expecting it to be newer one of 1_html and 2_html. Does anyone know of a walk-around like using the max() of bobobase_modification_time().timeTime() on the document itself and all the componets it dtml-vared? Forgive my using of non-Zope terms, for I'm new to Zope/Python. Wei He
BTW: This list if for development *of* Zope, the zope@zope.org list is better for questions bout developing *with* Zope. On to your question: There is no automatic way in which DTML can do this for you. This is simply because <dtml-var foo> doesn't tell Zope what foo is. Is it a document or a script that returns something different every time it is called or something else? In fact foo might different things at different times, if you aquire the template into different contexts. Anyhow, if you really want to set a Last-Modified header that reflects the latest of a group of documents, you can write a python script that accepts either a list of names or objects to test. For the latter here's a Py script named "setLastModTime" with a single argument, "*objects": last_mod = objects[0].bobobase_modification_time() for ob in objects[1:]: last_mod = max(last_mod, ob.bobobase_modification_time()) context.REQUEST.RESPONSE.setHeader('Last-Modified', last_mod.rfc822()) return last_mod # for debugging purposes Then from dtml: <dtml-call expr="setLastModTime(this(), fooMethod, barDocument, ...)"> hth, Casey On Fri, 2002-06-14 at 00:10, Wei He wrote:
Hi all,
Say you have 1_html with only one line: <dtml-var 2_html>
When you HEAD http://xxx/1_html, you get Last-Modified refelecting only the last modification time of 1_html, while most people is expecting it to be newer one of 1_html and 2_html.
Does anyone know of a walk-around like using the max() of bobobase_modification_time().timeTime() on the document itself and all the componets it dtml-vared?
Forgive my using of non-Zope terms, for I'm new to Zope/Python.
Wei He
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Casey Duncan wrote:
BTW: This list if for development *of* Zope, the zope@zope.org list is better for questions bout developing *with* Zope.
On to your question:
There is no automatic way in which DTML can do this for you. This is simply because <dtml-var foo> doesn't tell Zope what foo is. Is it a document or a script that returns something different every time it is called or something else? In fact foo might different things at different times, if you aquire the template into different contexts.
Anyhow, if you really want to set a Last-Modified header that reflects the latest of a group of documents, you can write a python script that accepts either a list of names or objects to test. For the latter here's a Py script named "setLastModTime" with a single argument, "*objects":
last_mod = objects[0].bobobase_modification_time() for ob in objects[1:]: last_mod = max(last_mod, ob.bobobase_modification_time()) context.REQUEST.RESPONSE.setHeader('Last-Modified', last_mod.rfc822()) return last_mod # for debugging purposes
Then from dtml:
<dtml-call expr="setLastModTime(this(), fooMethod, barDocument, ...)">
A similar approach would be for each page fragment to set the Last-Modified head if either there is no header set, or its own last-modified time is later than one that is set. -- Steve Alexander
On 14 Jun 2002, Casey Duncan wrote:
BTW: This list if for development *of* Zope, the zope@zope.org list is better for questions bout developing *with* Zope.
Thanks for your codes indeed. I posted it here because I thought only people have high developing skill care about whether their web pages are up-to-date to their readers and so care the HTTP Last-modified header. And why don't you think this issue is not for Zope developers? Dosen't Zope care about readers getting the accurate information? Although I'm new to Zope, I'm not new to mailing list. I know the mailing list rule but I just don't agree with your classification of my question. I'll post the next develope-with-zope issue to that list.
There is no automatic way in which DTML can do this for you. This is simply because <dtml-var foo> doesn't tell Zope what foo is. Is it a document or a script that returns something different every time it is called or something else? In fact foo might different things at different times, if you aquire the template into different contexts.
I think it isn't a bad thing DTML doing this for me. At least the Last-modified header can refelect the template modification time. Wei He
BTW: This list if for development *of* Zope, the zope@zope.org list is better for questions bout developing *with* Zope.
Thanks for your codes indeed. I posted it here because I thought only people have high developing skill care about whether their web pages are up-to-date to their readers and so care the HTTP Last-modified header.
Why do you think that? Surely all zope users will care about this? ;-) Besides, that's not the point, re-read Casey's email more carefully...
Although I'm new to Zope, I'm not new to mailing list. I know the mailing list rule but I just don't agree with your classification of my question.
Well, I second Casey's opinion :-P cheers, Chris
On Sun, 16 Jun 2002, Chris Withers wrote:
BTW: This list if for development *of* Zope, the zope@zope.org list is better for questions bout developing *with* Zope.
Thanks for your codes indeed. I posted it here because I thought only people have high developing skill care about whether their web pages are up-to-date to their readers and so care the HTTP Last-modified header.
Why do you think that? Surely all zope users will care about this? ;-) Besides, that's not the point, re-read Casey's email more carefully...
I don't think so. There are quite ofter a user should click CTRL and the refresh button to get the up-do-date page. This is because the Last-modified header not properly set. If DTML doesn't care about the modification time of it's code segments, it will definitely returns the template's modification time although the contents are keep on changing. My conclution is that if DTML doesn't do this or dosen't provide a simple way to do that, Zope may not care about the header at all. So dynamic webpage authors with basic skill could never control it. Only people have developing skill may do. Am I right? Here is Casey's email:
There is no automatic way in which DTML can do this for you. This is simply because <dtml-var foo> doesn't tell Zope what foo is. Is it a
No mater what foo is, there is surely a last modification time of foo. If it is a document. that's easy. If it is a script, there should be a method like self.setLastModificationTime(scriptTime). This method should decide if scriptTime is newer than DTML document's own update time and set it if so. Then it's up to the script writer to call the method with the current time if he/she want to disable browser's caching function.
document or a script that returns something different every time it is called or something else? In fact foo might different things at different times, if you aquire the template into different contexts.
What stops the main DTML document from knowing the last modification time of foo? In fact, Casey's script is just a walk-around. Script writers should manually create a list containing all code segments he/she dtml-vared. (Sorry for using this phrase to express my disagreement on choosing dtml-var against dtml-include). It's a boring task if there are many nested code segments included. I'm a PHP user for several years and I'm try to migrate part of my projects to Zope. Changing from PHP to DTML/Python is not a big deal. But I'm so used to the easy environment PHP provides coders. Wei He
On Sun, 16 Jun 2002, Chris Withers wrote:
Why do you think that? Surely all zope users will care about this? ;-) Besides, that's not the point, re-read Casey's email more carefully...
Although I'm new to Zope, I'm not new to mailing list. I know the mailing list rule but I just don't agree with your classification of my question.
Well, I second Casey's opinion :-P
Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a zope@zope.org question. The second is the question of whether or not that is the "right" behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. The answer to that may be, "there is no implementable algorithm that will work". That question still probably doesn't belong on zope-dev, though, but instead on zope3-dev <grin>. --RDM
R. David Murray writes:
... Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a zope@zope.org question. The second is the question of whether or not that is the "right" behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. Think about it. It is very difficult.
In order to determine the accurate modification time, you need to render the template (as it is non-trivial to determine the set of objects the rendering depends on without actually doing the rendering). Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects. Thus, you cannot have accurate modified headers for "HEAD" requests. Moreover, usually "HEAD" requests do not pass the necessary parameters for template rendering. To get it right for non-"HEAD" requests, you would need to pass an implicit state through most of the application. Any time, you access an object's attribute, you must take its last modification time into account, as the last modification may have changed the attribute you are accessing. I expect, it will give a significant performance penalty, at least, even when you come up with an ingenious implementation idea. Dieter
On Mon, 17 Jun 2002, Dieter Maurer wrote:
R. David Murray writes:
... Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a zope@zope.org question. The second is the question of whether or not that is the "right" behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. Think about it. It is very difficult.
In order to determine the accurate modification time, you need to render the template (as it is non-trivial to determine the set of objects the rendering depends on without actually doing the rendering).
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects. Thus, you cannot have accurate modified headers for "HEAD" requests. Moreover, usually "HEAD" requests do not pass the necessary parameters for template rendering.
Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic.
To get it right for non-"HEAD" requests, you would need to pass an implicit state through most of the application. Any time, you access an object's attribute, you must take its last modification time into account, as the last modification may have changed the attribute you are accessing.
That makes sense. But let me introduce my opinion from two aspects. 1. From the Zope developers' point of view, there definately needs a careful optimization to avoid unnecessary database update, even sometimes it may break the intrastructure. The key is that technologies server contents. MySQL and PHP's success is somehow an example. 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache. For example when I design my websites using PHP, all performance-sensitive database queries are executed before any contents output. The HTTP header is then generated according to the query results, which each of them have their own timestamp stored in the databse. That might be a weakness of a template system, but making good use of the protocol is a thing need to be considered whenever possible.
I expect, it will give a significant performance penalty, at least, even when you come up with an ingenious implementation idea.
I agree. There is always a trade off between funcationality and performance. But isn't Zope such an ingenious idea that makes content serving no longer as fast as they used to be? Wei He
Wei He wrote:
On Mon, 17 Jun 2002, Dieter Maurer wrote:
R. David Murray writes:
... Well, there's two aspects to this. The first one is the quesiton of *why* the last modified header is currently that of the outermost page template. That's a zope@zope.org question. The second is the question of whether or not that is the "right" behavior, and what it would take to make Zope smarter such that the last modified header would actually be accurate. Think about it. It is very difficult.
In order to determine the accurate modification time, you need to render the template (as it is non-trivial to determine the set of objects the rendering depends on without actually doing the rendering).
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects. Thus, you cannot have accurate modified headers for "HEAD" requests. Moreover, usually "HEAD" requests do not pass the necessary parameters for template rendering.
Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic.
HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes. cheers, oliver
On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic.
HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes.
Totally understood. But the question is what RFC says about the last-modified header. Shouldn't it reflect the latest update? Zope is facing this problem because it handles the HEAD request seperately. Am I right? I don't see any need to seperately handle the HEAD request. My hacking of the last-modified header is done execpt that HEAD and wget -S returns different headers. I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea? Cheers, Wei He
Wei He wrote:
On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
Would please go a little bit deeper giving an example what information HEAD requests don't pass to the server, although it's beyond this topic.
HEAD requests are required to have no side effects. On the other hand they are required to return the same response as GET requests without the BODY. So GET returning another last-modified header than HEAD would be in violation of the RFC. This gets worse by the fact that HEAD can be used for caching purposes.
Totally understood. But the question is what RFC says about the last-modified header. Shouldn't it reflect the latest update? Zope is facing this problem because it handles the HEAD request seperately. Am I right?
I don't see any need to seperately handle the HEAD request. My hacking of the last-modified header is done execpt that HEAD and wget -S returns different headers. I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea?
If you *really* want to, you can run a HEAD just like a GET, but after getting your last-modified and other details, abort the transaction to undo side-effects, then return the HEAD response. I would generally recommend against this, as it may end up being rather expensive. -- Steve Alexander
Wei He writes:
... 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache. I think you overestimate the importance of accurate "Last-Modified" headers.
In order for caching to be allowed, there must either be a "Last-Modified" or (alternatively) an "Etag" header. However, the value of the "Last-Modified" is almost irrelevant for caching. I think, it is only used when a HTTP cache validates on object, in that is uses this date in an "If-Modified-Since" request. I would use "Expires" and "Cache-Control" for cache control. Dieter
On Tue, 18 Jun 2002, Dieter Maurer wrote:
Wei He writes:
... 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache. I think you overestimate the importance of accurate "Last-Modified" headers.
Perhaps. But I think Etag, If-Modified-Since or whatever headers only make sense to a cache server that is designed to use these values, not for a generic one or the end users browser clients. And the last one is the real place caching-related headers making sence to. If I understand correctly, the Expires header can only give the client an impression how ofter a page is updated.
I would use "Expires" and "Cache-Control" for cache control.
Only when you want to disable the cache function, can these two headers be useful. Wei He
On Wednesday 19 Jun 2002 4:27 am, Wei He wrote:
On Tue, 18 Jun 2002, Dieter Maurer wrote:
Wei He writes:
... 2. From the website developers' point of view, there are already many guidlines on how to create a good webpage. Among them are using the HTTP Last-modification header to take the advantages of client cache.
I think you overestimate the importance of accurate "Last-Modified" headers.
The only thing Last-Modified can give you over Expires and Cache-Control is the possibility of sending a 304 Not Modified response code instead of a 200. If the response is cheap to calculate and transmit then a 200 may not be much more expensive than a 304, and you are correct that maintaining an accurate last-modified may not be cost-effective. However, if the response is expensive to transfer (that is, large) or expensive to calculate, then a 304 may be a significant saving.
Perhaps. But I think Etag, If-Modified-Since or whatever headers only make sense to a cache server that is designed to use these values, not for a generic one or the end users browser clients.
No, these headers are specified in RFC2616 and are commonly used by browsers, caches, and accelerators.
If I understand correctly, the Expires header can only give the client an impression how ofter a page is updated.
No, it is the opposite of that. It says how long you can assume it will not change.
I would use "Expires" and "Cache-Control" for cache control.
Only when you want to disable the cache function, can these two headers be useful.
I suggest you read RFC2616.
IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time. I think the Last-modified header should only be properly calculated for objects whose 'bobobase_modification_time' actually reflects the state of the object as seen from someone rendering it directly, such as File and Image objects. A single <dtml-var ZopeTime> in a method is enough to render the Last-modified header dangerously inacurate, IMO. Zope is a dynamic web server. Most of the time, any hit returned by zope was dynamically generated just now, and that's what we should be telling web clients, with very specific exceptions, such as necessarily static content (Files and Images), cached methods (RAM cache manager), or methods where we programatically pretend the pages where not dynamically calculated (by manually setting headers). Cheers, leo. -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Just a follow up to Leonardo's comments. It would seem that DTML, zpt, or script (python or whatever) pages should seem, to the browser, to always be new. Things like Portal Documents (In CMF) are non-programatic (in fact, I think most of the standard Portal types are static), and so they ought to be able to rely on their modification date/time. If all static objects defined (via a mixin, or just compliance with a new API, whatever), a method (for example) "LastModified", then the HEAD could return the correct time/date if this is found, and the current time/date in all other cases. This would allow authors who want to add this functionality the option of doing so, but would not cause major lossage if they did not. Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Leonardo Rochael Almeida" <leo@hiper.com.br> To: "Zope Developers list" <zope-dev@zope.org> Sent: Wednesday, June 19, 2002 5:37 PM Subject: [Zope-dev] let's just get rid of it (was: Last-modified and bobobase_modification_time)
IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time.
I think the Last-modified header should only be properly calculated for objects whose 'bobobase_modification_time' actually reflects the state of the object as seen from someone rendering it directly, such as File and Image objects.
A single <dtml-var ZopeTime> in a method is enough to render the Last-modified header dangerously inacurate, IMO.
Zope is a dynamic web server. Most of the time, any hit returned by zope was dynamically generated just now, and that's what we should be telling web clients, with very specific exceptions, such as necessarily static content (Files and Images), cached methods (RAM cache manager), or methods where we programatically pretend the pages where not dynamically calculated (by manually setting headers).
Cheers, leo.
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Leonardo Rochael Almeida writes:
IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time. Most Zope objects do not send "Last-Modified" headers, unless you use an HTTP cache manager. File objects (and derived objects) do but there it is justified.
However, Zope seems to send a bogus ETag header. The HTTP spec says that the ETag must uniquely identify the current incarnation of the entity. Especially, the ETag should change, when the entity is modified. But Zope sends empty "ETag" headers, allowing HTTP compatible caches to cache the pages. This seems to be a bug with the consequence of unanticipated caching problems. Dieter
The sending of an empty ETag header is a workaround to get Zope working with M$ Office through Webdav. But this header should be only be send on the WebDAV port. Andreas --On Thursday, June 20, 2002 21:16 +0200 Dieter Maurer <dieter@handshake.de> wrote:
Leonardo Rochael Almeida writes:
IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time. Most Zope objects do not send "Last-Modified" headers, unless you use an HTTP cache manager. File objects (and derived objects) do but there it is justified.
However, Zope seems to send a bogus ETag header. The HTTP spec says that the ETag must uniquely identify the current incarnation of the entity. Especially, the ETag should change, when the entity is modified. But Zope sends empty "ETag" headers, allowing HTTP compatible caches to cache the pages.
This seems to be a bug with the consequence of unanticipated caching problems.
Dieter
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
--------------------------------------------------------------------- - Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - - "Life is too short to (re)write parsers" - ---------------------------------------------------------------------
On Thursday 20 Jun 2002 9:47 pm, Andreas Jung wrote:
The sending of an empty ETag header is a workaround to get Zope working with M$ Office through Webdav. But this header should be only be send on the WebDAV port.
It looks like the DAV support is leaking out through the normal http port too. http://collector.zope.org/Zope/440 :-(
I will *try* to fix the problem before my vacation... -aj --On Friday, June 21, 2002 11:06 +0100 Toby Dickenson I<tdickenson@geminidataloggers.com> wrote:
On Thursday 20 Jun 2002 9:47 pm, Andreas Jung wrote:
The sending of an empty ETag header is a workaround to get Zope working with M$ Office through Webdav. But this header should be only be send on the WebDAV port.
It looks like the DAV support is leaking out through the normal http port too.
http://collector.zope.org/Zope/440
:-(
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
--------------------------------------------------------------------- - Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - - "Life is too short to (re)write parsers" - ---------------------------------------------------------------------
On Wed, 19 Jun 2002, Toby Dickenson wrote:
The only thing Last-Modified can give you over Expires and Cache-Control is the possibility of sending a 304 Not Modified response code instead of a 200.
If the response is cheap to calculate and transmit then a 200 may not be much more expensive than a 304, and you are correct that maintaining an accurate last-modified may not be cost-effective.
However, if the response is expensive to transfer (that is, large) or expensive to calculate, then a 304 may be a significant saving.
You just gave a clear explaination of how Last-Modified will influence the transfer. Let's see if everyone get this: If maintaning last-modified header is cheap, give an accurate result. If not, disable it to the client by sending an expire time in the past or something. In either case, Zope's current implementation needs to be changed. Because it will give the client a false impression that a page has not changed but actually it did.
If I understand correctly, the Expires header can only give the client an impression how ofter a page is updated.
No, it is the opposite of that. It says how long you can assume it will not change.
Aren't they the same? What I meant is the header doesn't guarantee that a page won't change before the coming expire time. So using this header won't help a client from getting an out-of-date page. The two meaningful uses of this header I can think of are: 1. Give an expire time in the past to force a client give up its cache. 2. Set an expire time a fixed period in the future, say 24 hours, to instruct the client that the page is updated daily.
I suggest you read RFC2616.
I'll do. Thanks. Wei He
On Thursday 20 Jun 2002 3:18 am, Wei He wrote:
On Wed, 19 Jun 2002, Toby Dickenson wrote:
The only thing Last-Modified can give you over Expires and Cache-Control is the possibility of sending a 304 Not Modified response code instead of a 200.
If the response is cheap to calculate and transmit then a 200 may not be much more expensive than a 304, and you are correct that maintaining an accurate last-modified may not be cost-effective.
However, if the response is expensive to transfer (that is, large) or expensive to calculate, then a 304 may be a significant saving.
You just gave a clear explaination of how Last-Modified will influence the transfer. Let's see if everyone get this:
If maintaning last-modified header is cheap, give an accurate result.
Yes
If not, disable it to the client by sending an expire time in the past or something.
No. Just send neither of Last-Modified or Expires.
In either case, Zope's current implementation needs to be changed. Because it will give the client a false impression that a page has not changed but actually it did.
What part of Zope gets this wrong?
If I understand correctly, the Expires header can only give the client an impression how ofter a page is updated.
No, it is the opposite of that. It says how long you can assume it will not change.
Aren't they the same? What I meant is the header doesn't guarantee that a page won't change before the coming expire time.
It tells clients that they can assume it will not change. (It would be impossible to guarantee that the page will not change, but this header is as close to a guarantee that you can give)
So using this header won't help a client from getting an out-of-date page. The two meaningful uses of this header I can think of are:
1. Give an expire time in the past to force a client give up its cache.
You only ever need to set an expires time in the past if you are setting Last-Modified, but want to inhibit caching. In your case the right thing to do is *not* set Last-Modified. If you do want to set Last-Modified, then RFC2616 provides better solutions than setting Expires in the past (which is really just a pre-RFC2616 hack). Check out Cache-Control:must-revalidate or Cache-Control:no-cache.
2. Set an expire time a fixed period in the future, say 24 hours, to instruct the client that the page is updated daily.
Yes. That is a good use of Expires. (Minor detail; dont set it to '24 hours in the future'. set it to '9AM tomorrow morning'. Otherwise a response cached just before your daily update will not be revalidated until 24 hours later. If you really want to say 'some time in the future' then Cache-Control:max-age=XXXX is more explicit.)
On Thu, 20 Jun 2002, Toby Dickenson wrote:
In either case, Zope's current implementation needs to be changed. Because it will give the client a false impression that a page has not changed but actually it did.
What part of Zope gets this wrong?
I just realized that the Last-Modified header in a GET request is NOT sent for a dynamic page. I was always asuming that it is the same as the HEAD request of the same URL. So at least the user can get correct information cause the client cache function will not work. Whether a cache server can handle this situation or whether RFC allows doing this (haven't read yet) is not a big problem. Sorry to everyone. And thank all of you. Wei He
Ah, well, that is not quite true. Zope (And apache, IIS, and others) may do the "right thing" and set or not set the headers, but IE at least definately DOES NOT do the correct thing when it comes to caching on the client (Even with caching disabled it still caches when it feels like it). Until clients improve, caching is just bad IMHO. Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Wei He" <hewei@mail.ied.ac.cn> To: "Toby Dickenson" <tdickenson@geminidataloggers.com> Cc: "Dieter Maurer" <dieter@handshake.de>; "R. David Murray" <bitz@bitdance.com>; "Chris Withers" <chrisw@nipltd.com>; "Casey Duncan" <casey@zope.com>; <zope-dev@zope.org> Sent: Thursday, June 20, 2002 2:45 PM Subject: Re: [Zope-dev] Last-modified and bobobase_modification_time
On Thu, 20 Jun 2002, Toby Dickenson wrote:
In either case, Zope's current implementation needs to be changed. Because it will give the client a false impression that a page has not changed but actually it did.
What part of Zope gets this wrong?
I just realized that the Last-Modified header in a GET request is NOT sent for a dynamic page. I was always asuming that it is the same as the HEAD request of the same URL.
So at least the user can get correct information cause the client cache function will not work. Whether a cache server can handle this situation or whether RFC allows doing this (haven't read yet) is not a big problem.
Sorry to everyone. And thank all of you.
Wei He
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects.
RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect, and both should have no side effects. On Tuesday 18 Jun 2002 10:26 am, Wei He wrote:
I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea?
Yes, I think that makes sense. A while ago the list discussed changing Zope's security declarations to add a way to specify whether a published method has significant side-effects. Side-effect-free methods can have HEAD and GET handled identically. Methods declared to have side-effects can only be accessed though a POST. I guess GET or HEAD on such methods would result in a 405 error (Method Not Allowed) (Such a change would also go a long way to reducing the scope of client-side-trojan vulnerabilities.)
Toby Dickenson wrote:
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects.
RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect, and both should have no side effects.
On Tuesday 18 Jun 2002 10:26 am, Wei He wrote:
I think the last step is to change the HEAD handling routine to the get information from GET. Does anyone have any idea?
Yes, I think that makes sense.
A while ago the list discussed changing Zope's security declarations to add a way to specify whether a published method has significant side-effects.
Side-effect-free methods can have HEAD and GET handled identically.
Methods declared to have side-effects can only be accessed though a POST. I guess GET or HEAD on such methods would result in a 405 error (Method Not Allowed)
(Such a change would also go a long way to reducing the scope of client-side-trojan vulnerabilities.)
Yes, and sadly this discussion died a miserable death. This is the point I omitted in my other reply. Dieter presumtion that GET can have sideeffect in zope, while right, shows exactly the problem with not following the RFC recommendations. I know that it is nearly impossible to follow this strictly - as far as I see it wouldn't even allow showing visitor stats on a frontpage - but zope should at least offer some infrastructure to handle this. And it absolutly should be stricter in it's management interfaces and such. To be clear, the RFC says: HEAD SHOULD NOT have sideffects. GET SHOULD NOT have sideffects. HEAD SHOULD return the same http-headers as GET. So none of the discussed changes would make zope violate the RFC, as it doesn't really require the above, it just recommends. cheers, oliver
On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
Toby Dickenson wrote:
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects.
RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect, and both should have no side effects.
This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology <grin>. The RFC does *NOT* say that GET and HEAD must have no side effects. That is just the simplist implementation of what it *dees* say, which is that GET and HEAD must be "idempotent". When Tim (I think it was) mentioned this in the first round of this disucssion, I had to look it up even though it is a good math term and I was a math major. What it means is that once you do a GET or HEAD request, any *subsequent* GET or HEAD request for that same URI may not change the state of the system. But the *first* access to that URI *can* change the state of the system. (See section 9.1.2.) So it seems to me that some of the concern I have seen in Zope code with avoiding "write on read", where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. There may well be other reasons to wish to avoid idempotent write-on-read (although I haven't thought of any yet), but RFC 2616 isn't one of them. NB: There seems to be a small bug in the spec, in that it does not say that any sequence of GET and HEAD requests on the same URI should be idempotent, but that is clearly the intent. --RDM PS: somehow, I don't think the spec writers thought much about hit counters...
On Tuesday 18 Jun 2002 2:15 pm, R. David Murray wrote:
RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect, and both should have no side effects.
This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology <grin>.
Yes, you are precisely correct. Thanks.
So it seems to me that some of the concern I have seen in Zope code with avoiding "write on read", where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec.
Yes, I dont think this is a problem.
NB: There seems to be a small bug in the spec, in that it does not say that any sequence of GET and HEAD requests on the same URI should be idempotent, but that is clearly the intent.
PS: somehow, I don't think the spec writers thought much about hit counters...
I like the phrase 'largely idempotent' to refer to what we want from a GET or a HEAD. A page with a hit counter is 'largely idempotent'.
R. David Murray wrote:
On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
Toby Dickenson wrote:
Rendering may produce side effects. But "HEAD" requests are required by HTTP not to have side effects.
RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect, and both should have no side effects.
First, your quoting is wrong, I didn't write that - talk about precisionist *g*.
This bugged me the first time this discussion went around, and I feel impelled to clearify it now, even though it is a little tangential to the core of the discussion. I guess I'm just a precisionist when it comes to terminology <grin>.
The RFC does *NOT* say that GET and HEAD must have no side effects. That is just the simplist implementation of what it *dees* say, which is that GET and HEAD must be "idempotent". When Tim (I think it was) mentioned this in the first round of this disucssion, I had to look it up even though it is a good math term and I was a math major.
This doesn't cover everything. First, you're right, the RFC indeed doesn't say MUST anywhere concerning the areas we are talking about. This is important. Zope does not violate the RFC. But, the RFC introduces two, let's say attributes to methods. One is idempotent, which is described in 9.1.2 which you righlty refer to. But, there's also the attribute safe, which is described in 9.1.1: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. Which is IMO exactly what we were talking about in that thread.
So it seems to me that some of the concern I have seen in Zope code with avoiding "write on read", where a GET request would otherwise trigger the one-time initialization of something in the database, is misplaced if the concern that motivates it is adhering to this spec. There may well be other reasons to wish to avoid idempotent write-on-read (although I haven't thought of any yet), but RFC 2616 isn't one of them.
Perhaps it is. I don't know the areas of the code where you have seen that, but it might be inspired not by the problem of idempotence, but of "safeness"
PS: somehow, I don't think the spec writers thought much about hit counters...
Lol, I think so too. cheers, oliver
On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
First, your quoting is wrong, I didn't write that - talk about precisionist *g*.
Check the number of >s. I don't know who lost the attribution of the inner part, but I just replied to your message and cut off everything after the last line quoted. The joys of email <grin>.
But, there's also the attribute safe, which is described in 9.1.1: [...] Which is IMO exactly what we were talking about in that thread.
Good point.
Perhaps it is. I don't know the areas of the code where you have seen that, but it might be inspired not by the problem of idempotence, but of "safeness"
It's not in the one example I could quote you, in Z3 (some hoops Casey jumped through to try to get the first call to look up a non-existent annotation in an AttributeAnnotatable from causing a ZODB write). But in other cases it might well be. In light of the hit counter use case, safety probably is much more important than idempotence. --RDM
Andy McKay wrote:
Teehee, Googlebot once hit ZopeZen for about 3 days in a continuous loop. Just use absolute_urls. Always. Its one of Zope's golden rules.
On a high volume site, the absolute_url can put a lot of unneccessary strain on the server :-S
Mind you I've abused acquistion a few times, it comes in useful to be able to have a different / shorter url point to the same object...
Indeed ;-) cheers, Chris
Shane Hathaway <shane@zope.com> writes:
Looking at the zope.org logs, I once saw GoogleBot generate URLs like this to zope.org of 1000 characters or more.
I had this too, leading to heavy traffic what's more. Cf http://zwiki.org/TheRobotProblem. Since then, as a temporary measure I set the "no robots" meta header in standard_wiki_header. Also, I cleaned up various link "holes" that would lead to infinite urls, using page_url() and wiki_url(). Finally, all wiki links were changed to use absolute urls (now optional). These things should help, and in fact it should be safe to allow google into a modern zwiki. Back to the original poster: yes, to avoid getting hammered by search engines it is necessary to make sure you expose no links leading to infinite urls. This may not be as hard as you think. Hackers can make up urls, but search engines don't (yet). -Simon
From: "Shane Hathaway" <shane@zope.com>
Well, I'm not so enthusiastic about it. Implicit acquisition in URLs leads to subtle bugs. One thing that just about every Zope site does is "acquire" images using a simple relative URL, but that makes the images much less cacheable.
Not if you do it with <dtml-var Image>, if I remember correctly. But sure, you are correct, it's possible to shoot yourself in the foot with this, and using relative urls is a sure way to do this. But having the possibility of letting an object be aqcuired by a whole bunch of subobjects, and overriding it further down in a tree, is still an amazingly great feature. If this feature can be modified so it's harder to shoot yourself in the foot (by for example forcing you to check an "Aqcuirable" check box before an object gets aquired or whatever), then fine, I have no problem with that. But aqcuisition still a great feature, and together with ZODB, one of the defining features that make Zope so powerful.
The browser can't know they are the same image and will have to fetch the image up to three times. This problem explodes on larger sites unless you educate HTML authors.
Well, I kinda thought that one of the points with Zope is that you don't need loads of HTML authors, because it's dead easy (thanks in much to aqcuisition) to have design templates, so that you don't *need* to have people doing html all over the place. :-)
On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote:
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development..... how does Zope 3 handle acquisition?
Toby Dickenson wrote:
My conclusions are:
a. implicit acquisition is dangerous
b. acquisition that searches outside the containment hierarchy is evil.
Im not keeping up with Zope 3 development..... how does Zope 3 handle acquisition?
There is no implicit acquisition in Zope 3. If there ever is, it will only be there as part of a Zope 2 compatibility library. Generally if you want something to be "acquired" by content that lies below it, you make that something a a View, a Resource, or a Utility, or a Service, or some other such thing. There is also an "acquire" namespace for paths and URLs. I haven't had cause to use that though. You make a choice as to what you want as Content and what you want as behind-the-scenes plumbing. -- Steve Alexander
Hmmm... interesting points... However I almost completely disagree. The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this. I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer. Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Toby Dickenson" <tdickenson@geminidataloggers.com> To: "Lennart Regebro" <lennart@torped.se>; "Wei He" <hewei@mail.ied.ac.cn>; <zope-dev@zope.org> Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote:
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation. Some specific problems that I have encountered: 1. Content that crosses between virtual hosts. If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another. 2. A page that uses a mix of context and containment If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image. My conclusions are: a. implicit acquisition is dangerous b. acquisition that searches outside the containment hierarchy is evil. Im not keeping up with Zope 3 development..... how does Zope 3 handle acquisition? _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
The namspace traversal in Zope 2 severely violates the principle of least surprise IMO. Although you can use this to clever ends, it opens up many doors to misuse of a site or even significant security holes. For instance, it used to be possible to access the Control Panel (and shutdown Zope) as a user defined in a subfolder of the root who had the local Manager role, just by forming a URL like: http://somezope/myfolder/Control_Panel/manage_main The point is that this grants way too much power to the end user to muck up the namespaces. It is difficult, if not impossible to design an app in Zope today that accounts for all possible namespace variations gracefully, since there are effectively an infinite number of them for every given object in Zope based on different URLs. Now I won't argue that implicit acquisition isn't useful. It rules in solving (and simplifying) problems in creating highly coordinated objects. But, being an implicit and magical thing, it is better if it is invoked through an explicit gesture rather than simply being there all the time. Having it around all the time also makes it easy to use it when its not the best (or most robust) solution because it also excels in creating namespace chaos that is difficult to predict and account for. This is what Zope3 realizes. -Casey On Thursday 30 May 2002 12:42 pm, Adrian Hungate wrote:
Hmmm... interesting points... However I almost completely disagree.
The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this.
I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer.
Adrian...
-- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
----- Original Message ----- From: "Toby Dickenson" <tdickenson@geminidataloggers.com> To: "Lennart Regebro" <lennart@torped.se>; "Wei He" <hewei@mail.ied.ac.cn>; <zope-dev@zope.org> Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic
On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote:
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation.
Some specific problems that I have encountered:
1. Content that crosses between virtual hosts.
If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another.
2. A page that uses a mix of context and containment
If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image.
My conclusions are:
a. implicit acquisition is dangerous
b. acquisition that searches outside the containment hierarchy is evil.
Im not keeping up with Zope 3 development..... how does Zope 3 handle acquisition?
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Hmm... being able to acquire the Control_Panel (or anything) and it taking on the wrong security context was a bug, and AFAIK it has been corrected. Before I start sounding like I did in a previous thread, I am starting to have some very serious doubts about the direction Z3 development is heading. I have been a strong proponent of Zope, in part because of the very features that people seem to be proudly proclaiming will be removed from, or at best depricated in, Z3... Bottom line, internal bugs to one side, Z2.x works a particular way, and is documented as doing so. This is a powerful and useful feature, and we are likely to severly impact the power and process of "Zopeing" by removing it. If we are still heading for "10x" we should be enhancing those features that set Zope apart from the competition, not removing features that make it different. Just my $0.02 Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Casey Duncan" <casey@zope.com> To: "Adrian Hungate" <adrian@haqa.co.uk>; "Toby Dickenson" <tdickenson@geminidataloggers.com>; "Lennart Regebro" <lennart@torped.se>; "Wei He" <hewei@mail.ied.ac.cn>; <zope-dev@zope.org> Sent: Thursday, May 30, 2002 6:43 PM Subject: Re: [Zope-dev] Zope logic The namspace traversal in Zope 2 severely violates the principle of least surprise IMO. Although you can use this to clever ends, it opens up many doors to misuse of a site or even significant security holes. For instance, it used to be possible to access the Control Panel (and shutdown Zope) as a user defined in a subfolder of the root who had the local Manager role, just by forming a URL like: http://somezope/myfolder/Control_Panel/manage_main The point is that this grants way too much power to the end user to muck up the namespaces. It is difficult, if not impossible to design an app in Zope today that accounts for all possible namespace variations gracefully, since there are effectively an infinite number of them for every given object in Zope based on different URLs. Now I won't argue that implicit acquisition isn't useful. It rules in solving (and simplifying) problems in creating highly coordinated objects. But, being an implicit and magical thing, it is better if it is invoked through an explicit gesture rather than simply being there all the time. Having it around all the time also makes it easy to use it when its not the best (or most robust) solution because it also excels in creating namespace chaos that is difficult to predict and account for. This is what Zope3 realizes. -Casey On Thursday 30 May 2002 12:42 pm, Adrian Hungate wrote:
Hmmm... interesting points... However I almost completely disagree.
The only part of URL implicit acquisition that I have a problem with is acquiring from outside the VHost, but if you plan properly, you can even avoid this.
I have written several sites that use this feature, and I have found no significant problems with it, and as for it being a problem for caching proxies, many of the objects that get acquired are dynamic, and provide different content based on context, so multiple cache entries is the correct answer.
Adrian...
-- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
----- Original Message ----- From: "Toby Dickenson" <tdickenson@geminidataloggers.com> To: "Lennart Regebro" <lennart@torped.se>; "Wei He" <hewei@mail.ied.ac.cn>; <zope-dev@zope.org> Sent: Thursday, May 30, 2002 4:07 PM Subject: Re: [Zope-dev] Zope logic
On Thursday 30 May 2002 10:29 am, Lennart Regebro wrote:
It not only sounds good, but it is good.No, it' is fantastic. Amazing. Totally unbelivingly great! It's one of the best and main features of Zope.
Is anyone relying on your site to provide information? How do you test your site to make sure that every possible url (not just the ones you link to) do not give out misinformation.
Some specific problems that I have encountered:
1. Content that crosses between virtual hosts.
If two different virtual hosts come from the same zope then it is possible to construct a URL so that content from one site appears under the hostname (and https certificate!) of another.
2. A page that uses a mix of context and containment
If a page is built up with some content found from its context, and other content from containment, then it is possible to construct a URL so that apparently related information comes from unrelated objects. Imagine a medical imaging database, where it was possible for a page do display the wrong patient name above an image.
My conclusions are:
a. implicit acquisition is dangerous
b. acquisition that searches outside the containment hierarchy is evil.
Im not keeping up with Zope 3 development..... how does Zope 3 handle acquisition?
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Adrian Hungate wrote:
Bottom line, internal bugs to one side, Z2.x works a particular way, and is documented as doing so. This is a powerful and useful feature, and we are likely to severly impact the power and process of "Zopeing" by removing it. If we are still heading for "10x" we should be enhancing those features that set Zope apart from the competition, not removing features that make it different.
I think I'll prefer the power in Zope 3 to the confusion in Zope 2... My 2p, Chris
participants (16)
-
Adrian Hungate -
Andreas Jung -
Andy McKay -
Casey Duncan -
Chris Withers -
Dieter Maurer -
Lennart Regebro -
Leonardo Rochael Almeida -
Oliver Bleutgen -
R. David Murray -
Shane Hathaway -
Simon Michael -
Steve Alexander -
Tim Hoffman -
Toby Dickenson -
Wei He