Hi Rob, Finally I'm back in this list :-) So, you are totally right about the meaning of the "transient" property: nothing to do with caching. Thanks also for the nice write up about caching behaviors: I've added a link back to your post in issue #25. Caching support is definitely something high on Restlet 1.2 priority list, but I'm not too keen on changing the API in an incremental Restlet 1.1 release. I , will however make sure that Restlet 1.2 is released in time, adjusting the features scope if necessary. I'm hoping for a 1.2 M1 in January. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : Rob Heittman [mailto:[email protected]] Envoye : mardi 9 decembre 2008 03:48 A : [email protected] Objet : Re: REQUEST FireFox cache control Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the "transient" property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes() This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. <http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/> (which is hopefully correct), FF will only respond as expected if you also set "no-store". In otherwords, "Cache-control: no-cache no-store". See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 "no-cache" will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use "no-store" if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using "no-store" for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use "no-store" on pages that absolutely must not be reloaded for any reason, but generally use "no-cache" for good performance combined with good "liveness" of content. - R ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=990923
