RE: REQUEST FireFox cache control
Hi Bala, Restlet 2.0 does support all HTTP 1.1 caching headers such as Cache-Control. See this page for details: Mapping HTTP semantics http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/324-restlet/130-restl et.html Regarding integration with caching tools, you should have a look at those RFEs: Add caching support http://restlet.tigris.org/issues/show_bug.cgi?id=25 Add caching support to Filter according to incoming Tag http://restlet.tigris.org/issues/show_bug.cgi?id=772 We might provide integration with popular caching tools as Restlet extensions in the future. Feed-back/suggestions/contributions are welcome. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : jeudi 11 mars 2010 01:15 À : discuss@restlet.tigris.org; Jerome Louvel Objet : RE: REQUEST FireFox cache control Hi Jerome, We are planning to use RESTLET 2.0 as part of data services PoC. As Caching is one of the requirements, does RESTLET 2.0 support caching as indicated by you in this thread?. Also, any suggestions on integrating with EHCache as it is already used in our organization?. Any help would be highly appreciated. Thanks, Bala. 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:rob.heitt...@solertium.com] Envoye : mardi 9 decembre 2008 03:48 A : discuss@restlet.tigris.org 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#g etAttributes() 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-firef ox-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-fire fox-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=4447dsMessageId=2589120
RE: REQUEST FireFox cache control
Hi Jerome, We are planning to use RESTLET 2.0 as part of data services PoC. As Caching is one of the requirements, does RESTLET 2.0 support caching as indicated by you in this thread?. Also, any suggestions on integrating with EHCache as it is already used in our organization?. Any help would be highly appreciated. Thanks, Bala. 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:rob.heitt...@solertium.com] Envoye : mardi 9 decembre 2008 03:48 A : discuss@restlet.tigris.org 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=4447dsMessageId=2457868
RE: REQUEST FireFox cache control
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:rob.heitt...@solertium.com] Envoye : mardi 9 decembre 2008 03:48 A : discuss@restlet.tigris.org 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=4447dsMessageId=990923
Re: REQUEST FireFox cache control
Welcome back, Jerome! That timeframe works for me. On Tue, Dec 23, 2008 at 3:21 PM, Jerome Louvel jerome.lou...@noelios.comwrote: 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. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=990933
Re: REQUEST FireFox cache control
Hi, perfecto Rob, as usual! cheers, Thierry Boileau 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() http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#getAttributes%28%29 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. (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=4447dsMessageId=981564
RE: REQUEST FireFox cache control
Wow. Thanks for the great, detailed response. I will look at the non-standard header mechanism. And . I concur with you that IE isn't always right. Or worse, for things that you would think would be basic (like content-types, and cache control)-or at least handled consistently by 2008-IE, FF, Opera (and most certainly all others) have different ideas. Cliff Binstock Coyote Reporting _ From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 6:48 PM To: discuss@restlet.tigris.org Subject: 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#g etAttributes() 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-firef ox-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-fire fox-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=4447dsMessageId=981752
REQUEST FireFox cache control
It appears that Firefox doesn't respect expiration date or cache-control properly. I would like most/all of my routes to expire immediately (and require a reload). I'm guessing that Representation#setTransient sets the Cache-control: no-cache for the return headers. However, according to http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-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. REQUEST: Perhaps the indirect effect of setTransient could set both of these? Could someone point me to where the effect of #isTransient actually does something to the header? Thanks much, Cliff -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981380
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=4447dsMessageId=981443
