Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Malaka, Existing ETag support is implemented at the transport level to support the client-side caching. ie, we calculate the ETag value and add it to the response as ETag header. Client(Eg: browser) can cache this response and validate the response to the subsequent request using that ETag. I

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Keerthika, As Isuru mentioned ETag caching support is already implemented. But it only supports Strong ETag validation since in PassThroughHttpSender we have implemented the Handle ETag caching, by just hashing the message context with digestGenerator. So this gives the support for strong Etag

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

> > > What will happen in the following case? > >- Cache Expiry < Max-age && and the cache entry is evicted? > > I believe in that case we have to fetch it from BE? > Yes, if the Cache expiry time is less than the Max-age then cached response will be invalidated in the expiration time limit.

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi, Sorry ignore my previous mail. I meant to send it as a reply to another mail and mistakenly sent it here. Thanks, Riyafa On Wed, Jan 24, 2018 at 9:05 AM, Dimuthu Leelarathne wrote: > Hi Keerthika, > > What will happen in the following case? > >- Cache Expiry <

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Keerthika, What will happen in the following case? - Cache Expiry < Max-age && and the cache entry is evicted? I believe in that case we have to fetch it from BE? thanks, Dimuthu On Wed, Jan 24, 2018 at 8:02 AM, Riyafa Abdul Hameed wrote: > Hi, > > It was required

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi, It was required to support native JSON in the cache mediator and hence we had to use the JsonStreamBuilder. At the time of releasing it was mentioned that APIM still uses JsonBuilder and I created an issue[1] to address this if required. [1] https://github.com/wso2/product-ei/issues/916

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Kreethika, Yes, this is a long pending initiative that is required under the cache mediator. Anyway, I believe this may be more meaningful if you draw flow diagram + sequence diagram so, audience in this list able to fully understand the picture and the interaction of the middleman (i.e

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

+1. Thanks Riyafa for the suggestion. Thanks, Keerthika. On Fri, Jan 12, 2018 at 3:05 PM, Riyafa Abdul Hameed wrote: > Hi Keerthika, > > We should have an option for disregarding the cache-control headers and > the default value should be that the cache-control headers be

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Keerthika, We should have an option for disregarding the cache-control headers and the default value should be that the cache-control headers be disregarded. This is because the current cache mediator is written so that it is fully backward compatible with the older versions of the cache

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Thanks Isuru. Will check the existing functionality. @Vijitha, +1 for providing the configuration option for omitting the cache-control headers. @Sanjeewa Will check with the latest cache mediator. Thanks, Keerthika. On Fri, Jan 12, 2018 at 12:16 PM, Vijitha Ekanayake

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Sanjeewa, On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda wrote: > So i think we can add latest cache mediator dependency to API Manager > 2.2.0 branch and test this feature. > If there are any gaps in documents or implementation we will be able to > fix them and

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

So i think we can add latest cache mediator dependency to API Manager 2.2.0 branch and test this feature. If there are any gaps in documents or implementation we will be able to fix them and officially support this feature from 2.2.0 onward. WDYT? @Vijitha, Cache mediator can engage per API

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Keerthika, As Shazni mentioned this is a very useful addition to the cache mediator functionality. I believe the suggested Cache mediator modifications compliant with RFC-2616[1]. i.e. wherever the specification shows MUST, MUST NOT, SHOULD, or SHOULD NOT for HTTP caches, the cache mediator

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Keerthika, ETag caching support is already implemented at the http transport level. This feature was introduced long time ago but still the documentation is not added to the wiki. Please refer to following jiras for more information. https://wso2.org/jira/browse/ESBJAVA-3504

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi Shazni, Please find the answers inline. > > 1. Does the user specify whether the ETag header should present in the > response or not? Or is it always available if the cache mediator is used? > If the backend returns the response with ETag header, cahce mediator always need to validate the

Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers

This is a very useful addition. ETag header is particularly useful. I have a few questions. 1. Does the user specify whether the ETag header should present in the response or not? Or is it always available if the cache mediator is used? > >- If it is available and ETag is present in the

[Architecture] [RRT] Improving caching based on cache-control and ETag headers

Hi All, In the current cache mediator implementation, cache control headers and ETag haven't been considered when serving responses through the cache mediator. Basically, it caches all responses and responds with same headers for the subsequent requests. I am planning to improve the current cache