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

[Keerthika Mahendralingam]

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 am not
doing any modification in that implementation.

In my case, when we have the no-cache header in the backend response that
means we can cache the response at the cache mediator level but we need to
verify the cached response before returning it to the user for the
subsequent call. So what we need to do is, if we have the no-cache and ETag
are present in the cached response, then we need to send a request with the
"If-not-match" header to the backend and if we get 304 response then we
should return the response which is cached already to the user. Otherwise,
we need to cache the newly returned response and return it to the user.


Thanks,
Keerthika.

On Fri, Jan 26, 2018 at 4:50 PM, Malaka Gangananda  wrote:

> 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 validation.
> But to support weak Etag validation we need to check Semantic equivalence
> of two representation.
>
> So are we going to implement support for Weak Etag validation as well ?.
>
> Thanks,
>
> On Wed, Jan 24, 2018 at 9:55 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>>
>>> 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. So we ned to get
>> the response from BE.
>>
>>>
>>> thanks,
>>> Dimuthu
>>>
>>>
>>> On Wed, Jan 24, 2018 at 8:02 AM, Riyafa Abdul Hameed 
>>> wrote:
>>>
 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

 Thanks,
 Riyafa

 On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan 
 wrote:

> 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
> Integration layer) and that may be helpful when writing documentation
>
 Will send those ASAP Dushan.
>>
>> Thanks,
>> Keerthika.
>>
>>>
> Cheers,
> Dushan
>
> On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> +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
>>> disregarded. This is because the current cache mediator is written so 
>>> that
>>> it is fully backward compatible with the older versions of the cache
>>> mediators. Any one using cache mediator in a synape configuration in an
>>> older version can use the same synapse configuration in the new version 
>>> and
>>> can expect the same behavior. If he/she wants to make use of the new
>>> features he/she may do so by editing the synapse configurations.
>>>
>>> Thanks,
>>> Riyafa
>>>
>>>
>>> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 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 <
 vijit...@wso2.com> wrote:

> Hi Sanjeewa,
>
>
> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
> sanje...@wso2.com> 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 

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

[Malaka Gangananda]

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 validation.
But to support weak Etag validation we need to check Semantic equivalence
of two representation.

So are we going to implement support for Weak Etag validation as well ?.

Thanks,

On Wed, Jan 24, 2018 at 9:55 AM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

>
>> 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. So we ned to get
> the response from BE.
>
>>
>> thanks,
>> Dimuthu
>>
>>
>> On Wed, Jan 24, 2018 at 8:02 AM, Riyafa Abdul Hameed 
>> wrote:
>>
>>> 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
>>>
>>> Thanks,
>>> Riyafa
>>>
>>> On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan 
>>> wrote:
>>>
 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
 Integration layer) and that may be helpful when writing documentation

>>> Will send those ASAP Dushan.
>
> Thanks,
> Keerthika.
>
>>
 Cheers,
 Dushan

 On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
 keerth...@wso2.com> wrote:

> +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
>> disregarded. This is because the current cache mediator is written so 
>> that
>> it is fully backward compatible with the older versions of the cache
>> mediators. Any one using cache mediator in a synape configuration in an
>> older version can use the same synapse configuration in the new version 
>> and
>> can expect the same behavior. If he/she wants to make use of the new
>> features he/she may do so by editing the synapse configurations.
>>
>> Thanks,
>> Riyafa
>>
>>
>> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> 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 <
>>> vijit...@wso2.com> wrote:
>>>
 Hi Sanjeewa,


 On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
 sanje...@wso2.com> 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 officially support this feature from 2.2.0 
> onward.
> WDYT?
>

 +1 for this approach.

>
> @Vijitha, Cache mediator can engage per API basis. So if someone
> do not interested on caching they can simply remove cache mediator 
> for that
> particular mediation flow.
>

 I intended to state just an option of disregarding the HTTP caching
 however not the response caching. Shouldn't it be valuable to have a 
 design
 alternative to disregard the HTTP Caching yet not the default response
 caching?

 Thanks.

>
> Thanks,
> Sanjeewa.
>
> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana 
> wrote:
>
>> 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 

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

[Keerthika Mahendralingam]

>
>
> 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. So we ned to get the
response from BE.

>
> thanks,
> Dimuthu
>
>
> On Wed, Jan 24, 2018 at 8:02 AM, Riyafa Abdul Hameed 
> wrote:
>
>> 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
>>
>> Thanks,
>> Riyafa
>>
>> On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan 
>> wrote:
>>
>>> 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
>>> Integration layer) and that may be helpful when writing documentation
>>>
>> Will send those ASAP Dushan.

Thanks,
Keerthika.

>
>>> Cheers,
>>> Dushan
>>>
>>> On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 +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
> disregarded. This is because the current cache mediator is written so that
> it is fully backward compatible with the older versions of the cache
> mediators. Any one using cache mediator in a synape configuration in an
> older version can use the same synapse configuration in the new version 
> and
> can expect the same behavior. If he/she wants to make use of the new
> features he/she may do so by editing the synapse configurations.
>
> Thanks,
> Riyafa
>
>
> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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 <
>> vijit...@wso2.com> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>>
>>> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> 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 officially support this feature from 2.2.0 onward.
 WDYT?

>>>
>>> +1 for this approach.
>>>

 @Vijitha, Cache mediator can engage per API basis. So if someone do
 not interested on caching they can simply remove cache mediator for 
 that
 particular mediation flow.

>>>
>>> I intended to state just an option of disregarding the HTTP caching
>>> however not the response caching. Shouldn't it be valuable to have a 
>>> design
>>> alternative to disregard the HTTP Caching yet not the default response
>>> caching?
>>>
>>> Thanks.
>>>

 Thanks,
 Sanjeewa.

 On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana 
 wrote:

> 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
>
> https://wso2.org/jira/browse/DOCUMENTATION-1435
>
>
> Thanks.
>
>
> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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

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

[Riyafa Abdul Hameed]

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 < 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 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
>>
>> Thanks,
>> Riyafa
>>
>> On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan 
>> wrote:
>>
>>> 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
>>> Integration layer) and that may be helpful when writing documentation
>>>
>>> Cheers,
>>> Dushan
>>>
>>> On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 +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
> disregarded. This is because the current cache mediator is written so that
> it is fully backward compatible with the older versions of the cache
> mediators. Any one using cache mediator in a synape configuration in an
> older version can use the same synapse configuration in the new version 
> and
> can expect the same behavior. If he/she wants to make use of the new
> features he/she may do so by editing the synapse configurations.
>
> Thanks,
> Riyafa
>
>
> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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 <
>> vijit...@wso2.com> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>>
>>> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> 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 officially support this feature from 2.2.0 onward.
 WDYT?

>>>
>>> +1 for this approach.
>>>

 @Vijitha, Cache mediator can engage per API basis. So if someone do
 not interested on caching they can simply remove cache mediator for 
 that
 particular mediation flow.

>>>
>>> I intended to state just an option of disregarding the HTTP caching
>>> however not the response caching. Shouldn't it be valuable to have a 
>>> design
>>> alternative to disregard the HTTP Caching yet not the default response
>>> caching?
>>>
>>> Thanks.
>>>

 Thanks,
 Sanjeewa.

 On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana 
 wrote:

> 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
>
> https://wso2.org/jira/browse/DOCUMENTATION-1435
>
>
> Thanks.
>
>
> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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

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

[Dimuthu Leelarathne]

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 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
>
> Thanks,
> Riyafa
>
> On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan  wrote:
>
>> 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
>> Integration layer) and that may be helpful when writing documentation
>>
>> Cheers,
>> Dushan
>>
>> On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> +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 disregarded.
 This is because the current cache mediator is written so that it is fully
 backward compatible with the older versions of the cache mediators. Any one
 using cache mediator in a synape configuration in an older version can use
 the same synapse configuration in the new version and can expect the same
 behavior. If he/she wants to make use of the new features he/she may do so
 by editing the synapse configurations.

 Thanks,
 Riyafa


 On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
 keerth...@wso2.com> wrote:

> 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  > wrote:
>
>> Hi Sanjeewa,
>>
>>
>> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
>> sanje...@wso2.com> 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 officially support this feature from 2.2.0 onward.
>>> WDYT?
>>>
>>
>> +1 for this approach.
>>
>>>
>>> @Vijitha, Cache mediator can engage per API basis. So if someone do
>>> not interested on caching they can simply remove cache mediator for that
>>> particular mediation flow.
>>>
>>
>> I intended to state just an option of disregarding the HTTP caching
>> however not the response caching. Shouldn't it be valuable to have a 
>> design
>> alternative to disregard the HTTP Caching yet not the default response
>> caching?
>>
>> Thanks.
>>
>>>
>>> Thanks,
>>> Sanjeewa.
>>>
>>> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana 
>>> wrote:
>>>
 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

 https://wso2.org/jira/browse/DOCUMENTATION-1435


 Thanks.


 On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
 keerth...@wso2.com> wrote:

> 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 response before sending the 
> cached
> response to the user.
>
>>
>>>- If it is available and ETag is present in the cached
>>>response, make a request with "If-None-Match" header with the 
>>> ETag value.
>>>
>>>
>>>- If the server returns "304 Not 

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

[Riyafa Abdul Hameed]

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

Thanks,
Riyafa

On Wed, Jan 24, 2018 at 3:40 AM, Dushan Abeyruwan  wrote:

> 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
> Integration layer) and that may be helpful when writing documentation
>
> Cheers,
> Dushan
>
> On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> +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 disregarded.
>>> This is because the current cache mediator is written so that it is fully
>>> backward compatible with the older versions of the cache mediators. Any one
>>> using cache mediator in a synape configuration in an older version can use
>>> the same synapse configuration in the new version and can expect the same
>>> behavior. If he/she wants to make use of the new features he/she may do so
>>> by editing the synapse configurations.
>>>
>>> Thanks,
>>> Riyafa
>>>
>>>
>>> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 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 
 wrote:

> Hi Sanjeewa,
>
>
> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda <
> sanje...@wso2.com> 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 officially support this feature from 2.2.0 onward.
>> WDYT?
>>
>
> +1 for this approach.
>
>>
>> @Vijitha, Cache mediator can engage per API basis. So if someone do
>> not interested on caching they can simply remove cache mediator for that
>> particular mediation flow.
>>
>
> I intended to state just an option of disregarding the HTTP caching
> however not the response caching. Shouldn't it be valuable to have a 
> design
> alternative to disregard the HTTP Caching yet not the default response
> caching?
>
> Thanks.
>
>>
>> Thanks,
>> Sanjeewa.
>>
>> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana 
>> wrote:
>>
>>> 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
>>>
>>> https://wso2.org/jira/browse/DOCUMENTATION-1435
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 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 response before sending the cached
 response to the user.

>
>>- If it is available and ETag is present in the cached
>>response, make a request with "If-None-Match" header with the 
>> ETag value.
>>
>>
>>- If the server returns "304 Not Modified" response returns
>>the cached response to the user.
>>
>> 2. If the caller makes a request with "If-None-Match" header with
> the ETag value and if it matched, why would you need to respond with 
> the
> cached message. Shouldn't it be only 304 with empty message as the 
> response
> hasn't changed?
>
 I considered only the use case where the 

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

[Dushan Abeyruwan]

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
Integration layer) and that may be helpful when writing documentation

Cheers,
Dushan

On Fri, Jan 12, 2018 at 1:37 AM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> +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 disregarded.
>> This is because the current cache mediator is written so that it is fully
>> backward compatible with the older versions of the cache mediators. Any one
>> using cache mediator in a synape configuration in an older version can use
>> the same synapse configuration in the new version and can expect the same
>> behavior. If he/she wants to make use of the new features he/she may do so
>> by editing the synapse configurations.
>>
>> Thanks,
>> Riyafa
>>
>>
>> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> 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 
>>> wrote:
>>>
 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 officially support this feature from 2.2.0 onward.
> WDYT?
>

 +1 for this approach.

>
> @Vijitha, Cache mediator can engage per API basis. So if someone do
> not interested on caching they can simply remove cache mediator for that
> particular mediation flow.
>

 I intended to state just an option of disregarding the HTTP caching
 however not the response caching. Shouldn't it be valuable to have a design
 alternative to disregard the HTTP Caching yet not the default response
 caching?

 Thanks.

>
> Thanks,
> Sanjeewa.
>
> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:
>
>> 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
>>
>> https://wso2.org/jira/browse/DOCUMENTATION-1435
>>
>>
>> Thanks.
>>
>>
>> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> 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 response before sending the cached response 
>>> to
>>> the user.
>>>

>- If it is available and ETag is present in the cached
>response, make a request with "If-None-Match" header with the ETag 
> value.
>
>
>- If the server returns "304 Not Modified" response returns
>the cached response to the user.
>
> 2. If the caller makes a request with "If-None-Match" header with
 the ETag value and if it matched, why would you need to respond with 
 the
 cached message. Shouldn't it be only 304 with empty message as the 
 response
 hasn't changed?

>>> I considered only the use case where the backend server response has
>>> the ETag header. But we need to consider the request as well. As you 
>>> said,
>>> if the user sends a request with "If-None-Match" header with the
>>> ETag value and if it is matched with the cached response ETag value, 
>>> then
>>> we need to send 304 response. If it is not matched, cache mediator 
>>> should
>>> validate the cached response with the backend and return the response to
>>> the user. Thanks for pointing this out.
>>>


> *Honor "max-age" 

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

[Keerthika Mahendralingam]

+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 disregarded.
> This is because the current cache mediator is written so that it is fully
> backward compatible with the older versions of the cache mediators. Any one
> using cache mediator in a synape configuration in an older version can use
> the same synapse configuration in the new version and can expect the same
> behavior. If he/she wants to make use of the new features he/she may do so
> by editing the synapse configurations.
>
> Thanks,
> Riyafa
>
>
> On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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 
>> wrote:
>>
>>> 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 officially support this feature from 2.2.0 onward.
 WDYT?

>>>
>>> +1 for this approach.
>>>

 @Vijitha, Cache mediator can engage per API basis. So if someone do not
 interested on caching they can simply remove cache mediator for that
 particular mediation flow.

>>>
>>> I intended to state just an option of disregarding the HTTP caching
>>> however not the response caching. Shouldn't it be valuable to have a design
>>> alternative to disregard the HTTP Caching yet not the default response
>>> caching?
>>>
>>> Thanks.
>>>

 Thanks,
 Sanjeewa.

 On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:

> 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
>
> https://wso2.org/jira/browse/DOCUMENTATION-1435
>
>
> Thanks.
>
>
> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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 response before sending the cached response 
>> to
>> the user.
>>
>>>
- If it is available and ETag is present in the cached
response, make a request with "If-None-Match" header with the ETag 
 value.


- If the server returns "304 Not Modified" response returns the
cached response to the user.

 2. If the caller makes a request with "If-None-Match" header with
>>> the ETag value and if it matched, why would you need to respond with the
>>> cached message. Shouldn't it be only 304 with empty message as the 
>>> response
>>> hasn't changed?
>>>
>> I considered only the use case where the backend server response has
>> the ETag header. But we need to consider the request as well. As you 
>> said,
>> if the user sends a request with "If-None-Match" header with the
>> ETag value and if it is matched with the cached response ETag value, then
>> we need to send 304 response. If it is not matched, cache mediator should
>> validate the cached response with the backend and return the response to
>> the user. Thanks for pointing this out.
>>
>>>
>>>
 *Honor "max-age" cache-control header*If the "max-age" header
 presents in the response it specifies the maximum time in seconds that 
 the
 fetched response is allowed to be reused from the time of the request. 
 So
 the response should be cached and reused within the max-age time 
 limit. So
 the Cache mediator should honor max-age instead of timeout 
 configuration if
 it is less than the timeout configuration.
>>>
>>>
>>> 3. What is the behavior when the timeout configuration is less than
>>> the max-age cache-control header?
>>>
>> Cached response 

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

[Riyafa Abdul Hameed]

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 mediators. Any one
using cache mediator in a synape configuration in an older version can use
the same synapse configuration in the new version and can expect the same
behavior. If he/she wants to make use of the new features he/she may do so
by editing the synapse configurations.

Thanks,
Riyafa


On Fri, Jan 12, 2018 at 12:24 PM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> 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 
> wrote:
>
>> 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 officially support this feature from 2.2.0 onward.
>>> WDYT?
>>>
>>
>> +1 for this approach.
>>
>>>
>>> @Vijitha, Cache mediator can engage per API basis. So if someone do not
>>> interested on caching they can simply remove cache mediator for that
>>> particular mediation flow.
>>>
>>
>> I intended to state just an option of disregarding the HTTP caching
>> however not the response caching. Shouldn't it be valuable to have a design
>> alternative to disregard the HTTP Caching yet not the default response
>> caching?
>>
>> Thanks.
>>
>>>
>>> Thanks,
>>> Sanjeewa.
>>>
>>> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:
>>>
 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

 https://wso2.org/jira/browse/DOCUMENTATION-1435


 Thanks.


 On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
 keerth...@wso2.com> wrote:

> 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 response before sending the cached response to
> the user.
>
>>
>>>- If it is available and ETag is present in the cached response,
>>>make a request with "If-None-Match" header with the ETag value.
>>>
>>>
>>>- If the server returns "304 Not Modified" response returns the
>>>cached response to the user.
>>>
>>> 2. If the caller makes a request with "If-None-Match" header with
>> the ETag value and if it matched, why would you need to respond with the
>> cached message. Shouldn't it be only 304 with empty message as the 
>> response
>> hasn't changed?
>>
> I considered only the use case where the backend server response has
> the ETag header. But we need to consider the request as well. As you said,
> if the user sends a request with "If-None-Match" header with the ETag
> value and if it is matched with the cached response ETag value, then we
> need to send 304 response. If it is not matched, cache mediator should
> validate the cached response with the backend and return the response to
> the user. Thanks for pointing this out.
>
>>
>>
>>> *Honor "max-age" cache-control header*If the "max-age" header
>>> presents in the response it specifies the maximum time in seconds that 
>>> the
>>> fetched response is allowed to be reused from the time of the request. 
>>> So
>>> the response should be cached and reused within the max-age time limit. 
>>> So
>>> the Cache mediator should honor max-age instead of timeout 
>>> configuration if
>>> it is less than the timeout configuration.
>>
>>
>> 3. What is the behavior when the timeout configuration is less than
>> the max-age cache-control header?
>>
> Cached response expires after the timeout limit.
>
> Thanks,
> Keerthika.
>
>>
>> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In the current cache mediator implementation, cache control headers
>>> and ETag haven't 

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

[Keerthika Mahendralingam]

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 
wrote:

> 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 officially support this feature from 2.2.0 onward.
>> WDYT?
>>
>
> +1 for this approach.
>
>>
>> @Vijitha, Cache mediator can engage per API basis. So if someone do not
>> interested on caching they can simply remove cache mediator for that
>> particular mediation flow.
>>
>
> I intended to state just an option of disregarding the HTTP caching
> however not the response caching. Shouldn't it be valuable to have a design
> alternative to disregard the HTTP Caching yet not the default response
> caching?
>
> Thanks.
>
>>
>> Thanks,
>> Sanjeewa.
>>
>> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:
>>
>>> 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
>>>
>>> https://wso2.org/jira/browse/DOCUMENTATION-1435
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 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 response before sending the cached response to
 the user.

>
>>- If it is available and ETag is present in the cached response,
>>make a request with "If-None-Match" header with the ETag value.
>>
>>
>>- If the server returns "304 Not Modified" response returns the
>>cached response to the user.
>>
>> 2. If the caller makes a request with "If-None-Match" header with the
> ETag value and if it matched, why would you need to respond with the 
> cached
> message. Shouldn't it be only 304 with empty message as the response 
> hasn't
> changed?
>
 I considered only the use case where the backend server response has
 the ETag header. But we need to consider the request as well. As you said,
 if the user sends a request with "If-None-Match" header with the ETag
 value and if it is matched with the cached response ETag value, then we
 need to send 304 response. If it is not matched, cache mediator should
 validate the cached response with the backend and return the response to
 the user. Thanks for pointing this out.

>
>
>> *Honor "max-age" cache-control header*If the "max-age" header
>> presents in the response it specifies the maximum time in seconds that 
>> the
>> fetched response is allowed to be reused from the time of the request. So
>> the response should be cached and reused within the max-age time limit. 
>> So
>> the Cache mediator should honor max-age instead of timeout configuration 
>> if
>> it is less than the timeout configuration.
>
>
> 3. What is the behavior when the timeout configuration is less than
> the max-age cache-control header?
>
 Cached response expires after the timeout limit.

 Thanks,
 Keerthika.

>
> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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
>> mediator with the following features:
>>
>>- Honor ETag header
>>- Honor "no-cache" & "no-store" cache-control header.
>>- Honor "max-age" cache-control header.
>>- Add Age header based on "max-age" cache-control header when
>>returning the cached response.
>>
>>
>> *1. ETag support:*
>> If ETag header is present in the response, subsequent requests need
>> to be issued with the "If-None-Match" header(with ETag value) and if the
>> requested resource is modified from the last response fetched time, a new
>> modified response 

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

[Vijitha Ekanayake]

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 officially support this feature from 2.2.0 onward.
> WDYT?
>

+1 for this approach.

>
> @Vijitha, Cache mediator can engage per API basis. So if someone do not
> interested on caching they can simply remove cache mediator for that
> particular mediation flow.
>

I intended to state just an option of disregarding the HTTP caching however
not the response caching. Shouldn't it be valuable to have a design
alternative to disregard the HTTP Caching yet not the default response
caching?

Thanks.

>
> Thanks,
> Sanjeewa.
>
> On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:
>
>> 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
>>
>> https://wso2.org/jira/browse/DOCUMENTATION-1435
>>
>>
>> Thanks.
>>
>>
>> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> 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 response before sending the cached response to
>>> the user.
>>>

>- If it is available and ETag is present in the cached response,
>make a request with "If-None-Match" header with the ETag value.
>
>
>- If the server returns "304 Not Modified" response returns the
>cached response to the user.
>
> 2. If the caller makes a request with "If-None-Match" header with the
 ETag value and if it matched, why would you need to respond with the cached
 message. Shouldn't it be only 304 with empty message as the response hasn't
 changed?

>>> I considered only the use case where the backend server response has the
>>> ETag header. But we need to consider the request as well. As you said, if
>>> the user sends a request with "If-None-Match" header with the ETag
>>> value and if it is matched with the cached response ETag value, then we
>>> need to send 304 response. If it is not matched, cache mediator should
>>> validate the cached response with the backend and return the response to
>>> the user. Thanks for pointing this out.
>>>


> *Honor "max-age" cache-control header*If the "max-age" header
> presents in the response it specifies the maximum time in seconds that the
> fetched response is allowed to be reused from the time of the request. So
> the response should be cached and reused within the max-age time limit. So
> the Cache mediator should honor max-age instead of timeout configuration 
> if
> it is less than the timeout configuration.


 3. What is the behavior when the timeout configuration is less than the
 max-age cache-control header?

>>> Cached response expires after the timeout limit.
>>>
>>> Thanks,
>>> Keerthika.
>>>

 On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
 keerth...@wso2.com> wrote:

> 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
> mediator with the following features:
>
>- Honor ETag header
>- Honor "no-cache" & "no-store" cache-control header.
>- Honor "max-age" cache-control header.
>- Add Age header based on "max-age" cache-control header when
>returning the cached response.
>
>
> *1. ETag support:*
> If ETag header is present in the response, subsequent requests need to
> be issued with the "If-None-Match" header(with ETag value) and if the
> requested resource is modified from the last response fetched time, a new
> modified response will be returned with new ETag. And this new response
> needs to be cached. If it is not modified, the server returns a "304 Not
> Modified" response. In that case, the cached response can be reused.
>
> Flow:
>
>- Cache mediator receives a request.
>- Check whether a cached response is available for the same
>request.
>- If it is available and ETag is present in the cached response,
>make a request with 

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

[Sanjeewa Malalgoda]

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 basis. So if someone do not
interested on caching they can simply remove cache mediator for that
particular mediation flow.

Thanks,
Sanjeewa.

On Fri, Jan 12, 2018 at 11:07 AM, Isuru Udana  wrote:

> 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
>
> https://wso2.org/jira/browse/DOCUMENTATION-1435
>
>
> Thanks.
>
>
> On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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 response before sending the cached response to
>> the user.
>>
>>>
- If it is available and ETag is present in the cached response,
make a request with "If-None-Match" header with the ETag value.


- If the server returns "304 Not Modified" response returns the
cached response to the user.

 2. If the caller makes a request with "If-None-Match" header with the
>>> ETag value and if it matched, why would you need to respond with the cached
>>> message. Shouldn't it be only 304 with empty message as the response hasn't
>>> changed?
>>>
>> I considered only the use case where the backend server response has the
>> ETag header. But we need to consider the request as well. As you said, if
>> the user sends a request with "If-None-Match" header with the ETag value
>> and if it is matched with the cached response ETag value, then we need to
>> send 304 response. If it is not matched, cache mediator should validate the
>> cached response with the backend and return the response to the user.
>> Thanks for pointing this out.
>>
>>>
>>>
 *Honor "max-age" cache-control header*If the "max-age" header presents
 in the response it specifies the maximum time in seconds that the fetched
 response is allowed to be reused from the time of the request. So the
 response should be cached and reused within the max-age time limit. So the
 Cache mediator should honor max-age instead of timeout configuration if it
 is less than the timeout configuration.
>>>
>>>
>>> 3. What is the behavior when the timeout configuration is less than the
>>> max-age cache-control header?
>>>
>> Cached response expires after the timeout limit.
>>
>> Thanks,
>> Keerthika.
>>
>>>
>>> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
>>> keerth...@wso2.com> wrote:
>>>
 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
 mediator with the following features:

- Honor ETag header
- Honor "no-cache" & "no-store" cache-control header.
- Honor "max-age" cache-control header.
- Add Age header based on "max-age" cache-control header when
returning the cached response.


 *1. ETag support:*
 If ETag header is present in the response, subsequent requests need to
 be issued with the "If-None-Match" header(with ETag value) and if the
 requested resource is modified from the last response fetched time, a new
 modified response will be returned with new ETag. And this new response
 needs to be cached. If it is not modified, the server returns a "304 Not
 Modified" response. In that case, the cached response can be reused.

 Flow:

- Cache mediator receives a request.
- Check whether a cached response is available for the same request.
- If it is available and ETag is present in the cached response,
make a request with "If-None-Match" header with the ETag value.
- If the server returns "304 Not Modified" response returns the
cached response to the user.
- If the server returns a new modified response(200 OK response)
then cache the newly returned response.


 *2. Honor "no-cache" and "no-store" header*

- If the "no-cache" header is present in the response it indicates
that the returned response can’t be used to satisfy a subsequent 
 request to
the 

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

[Vijitha Ekanayake]

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
endeavors to carry on in a way that fulfills those necessities. With that,
the end user has the assurance of adding cache mediator won't produce any
incorrect behavior.

Additionally, Shall we provide a configurations option to ignore the HTTP
Caching headers on the off chance that somebody isn't interested in HTTP
caching functionality?

WDYT?

[1]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Thanks.






On Fri, Jan 12, 2018 at 9:27 AM, Shazni Nazeer  wrote:

> 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 cached response, make
>>a request with "If-None-Match" header with the ETag value.
>>
>>
>>- If the server returns "304 Not Modified" response returns the
>>cached response to the user.
>>
>> 2. If the caller makes a request with "If-None-Match" header with the
> ETag value and if it matched, why would you need to respond with the cached
> message. Shouldn't it be only 304 with empty message as the response hasn't
> changed?
>
>
>> *Honor "max-age" cache-control header*If the "max-age" header presents
>> in the response it specifies the maximum time in seconds that the fetched
>> response is allowed to be reused from the time of the request. So the
>> response should be cached and reused within the max-age time limit. So the
>> Cache mediator should honor max-age instead of timeout configuration if it
>> is less than the timeout configuration.
>
>
> 3. What is the behavior when the timeout configuration is less than the
> max-age cache-control header?
>
> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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
>> mediator with the following features:
>>
>>- Honor ETag header
>>- Honor "no-cache" & "no-store" cache-control header.
>>- Honor "max-age" cache-control header.
>>- Add Age header based on "max-age" cache-control header when
>>returning the cached response.
>>
>>
>> *1. ETag support:*
>> If ETag header is present in the response, subsequent requests need to be
>> issued with the "If-None-Match" header(with ETag value) and if the
>> requested resource is modified from the last response fetched time, a new
>> modified response will be returned with new ETag. And this new response
>> needs to be cached. If it is not modified, the server returns a "304 Not
>> Modified" response. In that case, the cached response can be reused.
>>
>> Flow:
>>
>>- Cache mediator receives a request.
>>- Check whether a cached response is available for the same request.
>>- If it is available and ETag is present in the cached response, make
>>a request with "If-None-Match" header with the ETag value.
>>- If the server returns "304 Not Modified" response returns the
>>cached response to the user.
>>- If the server returns a new modified response(200 OK response) then
>>cache the newly returned response.
>>
>>
>> *2. Honor "no-cache" and "no-store" header*
>>
>>- If the "no-cache" header is present in the response it indicates
>>that the returned response can’t be used to satisfy a subsequent request 
>> to
>>the same URL without first checking with the server if the response has
>>changed. So before responding with the cached response cache mediator
>>should validate the response with ETag. This can be supported through the
>>ETag support.
>>- If the "no-store" header is present in the response, Cache mediator
>>should not cache the returned response.
>>
>> *3. Honor "max-age" cache-control header*
>> If the "max-age" header presents in the response it specifies the maximum
>> time in seconds that the fetched response is allowed to be reused from the
>> time of the request. So the response should be cached and reused within the
>> max-age time limit. So the Cache mediator should honor max-age instead of
>> timeout configuration if it is less than the timeout configuration.
>>
>> 4. *Include an ‘Age’ header with the response*
>> Cache mediator should return the true TTL value of a response without
>> altering the value of the cache-control max-age header returned by the
>> back-end.
>>
>>
>> Flow:
>>
>>   

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

[Isuru Udana]

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

https://wso2.org/jira/browse/DOCUMENTATION-1435


Thanks.


On Fri, Jan 12, 2018 at 10:51 AM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> 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 response before sending the cached response to
> the user.
>
>>
>>>- If it is available and ETag is present in the cached response,
>>>make a request with "If-None-Match" header with the ETag value.
>>>
>>>
>>>- If the server returns "304 Not Modified" response returns the
>>>cached response to the user.
>>>
>>> 2. If the caller makes a request with "If-None-Match" header with the
>> ETag value and if it matched, why would you need to respond with the cached
>> message. Shouldn't it be only 304 with empty message as the response hasn't
>> changed?
>>
> I considered only the use case where the backend server response has the
> ETag header. But we need to consider the request as well. As you said, if
> the user sends a request with "If-None-Match" header with the ETag value
> and if it is matched with the cached response ETag value, then we need to
> send 304 response. If it is not matched, cache mediator should validate the
> cached response with the backend and return the response to the user.
> Thanks for pointing this out.
>
>>
>>
>>> *Honor "max-age" cache-control header*If the "max-age" header presents
>>> in the response it specifies the maximum time in seconds that the fetched
>>> response is allowed to be reused from the time of the request. So the
>>> response should be cached and reused within the max-age time limit. So the
>>> Cache mediator should honor max-age instead of timeout configuration if it
>>> is less than the timeout configuration.
>>
>>
>> 3. What is the behavior when the timeout configuration is less than the
>> max-age cache-control header?
>>
> Cached response expires after the timeout limit.
>
> Thanks,
> Keerthika.
>
>>
>> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> 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
>>> mediator with the following features:
>>>
>>>- Honor ETag header
>>>- Honor "no-cache" & "no-store" cache-control header.
>>>- Honor "max-age" cache-control header.
>>>- Add Age header based on "max-age" cache-control header when
>>>returning the cached response.
>>>
>>>
>>> *1. ETag support:*
>>> If ETag header is present in the response, subsequent requests need to
>>> be issued with the "If-None-Match" header(with ETag value) and if the
>>> requested resource is modified from the last response fetched time, a new
>>> modified response will be returned with new ETag. And this new response
>>> needs to be cached. If it is not modified, the server returns a "304 Not
>>> Modified" response. In that case, the cached response can be reused.
>>>
>>> Flow:
>>>
>>>- Cache mediator receives a request.
>>>- Check whether a cached response is available for the same request.
>>>- If it is available and ETag is present in the cached response,
>>>make a request with "If-None-Match" header with the ETag value.
>>>- If the server returns "304 Not Modified" response returns the
>>>cached response to the user.
>>>- If the server returns a new modified response(200 OK response)
>>>then cache the newly returned response.
>>>
>>>
>>> *2. Honor "no-cache" and "no-store" header*
>>>
>>>- If the "no-cache" header is present in the response it indicates
>>>that the returned response can’t be used to satisfy a subsequent request 
>>> to
>>>the same URL without first checking with the server if the response has
>>>changed. So before responding with the cached response cache mediator
>>>should validate the response with ETag. This can be supported through the
>>>ETag support.
>>>- If the "no-store" header is present in the response, Cache
>>>mediator should not cache the returned response.
>>>
>>> *3. Honor "max-age" cache-control header*
>>> If the "max-age" header presents in the response it specifies the
>>> maximum time in seconds that the fetched response is allowed to be reused
>>> from the time of the request. So the response should be cached 

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

[Keerthika Mahendralingam]

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 response before sending the cached response to the
user.

>
>>- If it is available and ETag is present in the cached response, make
>>a request with "If-None-Match" header with the ETag value.
>>
>>
>>- If the server returns "304 Not Modified" response returns the
>>cached response to the user.
>>
>> 2. If the caller makes a request with "If-None-Match" header with the
> ETag value and if it matched, why would you need to respond with the cached
> message. Shouldn't it be only 304 with empty message as the response hasn't
> changed?
>
I considered only the use case where the backend server response has the
ETag header. But we need to consider the request as well. As you said, if
the user sends a request with "If-None-Match" header with the ETag value
and if it is matched with the cached response ETag value, then we need to
send 304 response. If it is not matched, cache mediator should validate the
cached response with the backend and return the response to the user.
Thanks for pointing this out.

>
>
>> *Honor "max-age" cache-control header*If the "max-age" header presents
>> in the response it specifies the maximum time in seconds that the fetched
>> response is allowed to be reused from the time of the request. So the
>> response should be cached and reused within the max-age time limit. So the
>> Cache mediator should honor max-age instead of timeout configuration if it
>> is less than the timeout configuration.
>
>
> 3. What is the behavior when the timeout configuration is less than the
> max-age cache-control header?
>
Cached response expires after the timeout limit.

Thanks,
Keerthika.

>
> On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> 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
>> mediator with the following features:
>>
>>- Honor ETag header
>>- Honor "no-cache" & "no-store" cache-control header.
>>- Honor "max-age" cache-control header.
>>- Add Age header based on "max-age" cache-control header when
>>returning the cached response.
>>
>>
>> *1. ETag support:*
>> If ETag header is present in the response, subsequent requests need to be
>> issued with the "If-None-Match" header(with ETag value) and if the
>> requested resource is modified from the last response fetched time, a new
>> modified response will be returned with new ETag. And this new response
>> needs to be cached. If it is not modified, the server returns a "304 Not
>> Modified" response. In that case, the cached response can be reused.
>>
>> Flow:
>>
>>- Cache mediator receives a request.
>>- Check whether a cached response is available for the same request.
>>- If it is available and ETag is present in the cached response, make
>>a request with "If-None-Match" header with the ETag value.
>>- If the server returns "304 Not Modified" response returns the
>>cached response to the user.
>>- If the server returns a new modified response(200 OK response) then
>>cache the newly returned response.
>>
>>
>> *2. Honor "no-cache" and "no-store" header*
>>
>>- If the "no-cache" header is present in the response it indicates
>>that the returned response can’t be used to satisfy a subsequent request 
>> to
>>the same URL without first checking with the server if the response has
>>changed. So before responding with the cached response cache mediator
>>should validate the response with ETag. This can be supported through the
>>ETag support.
>>- If the "no-store" header is present in the response, Cache mediator
>>should not cache the returned response.
>>
>> *3. Honor "max-age" cache-control header*
>> If the "max-age" header presents in the response it specifies the maximum
>> time in seconds that the fetched response is allowed to be reused from the
>> time of the request. So the response should be cached and reused within the
>> max-age time limit. So the Cache mediator should honor max-age instead of
>> timeout configuration if it is less than the timeout configuration.
>>
>> 4. *Include an ‘Age’ header with the response*
>> Cache mediator should return the true TTL value of a response without
>> altering the value of the cache-control max-age header returned by the
>> back-end.
>>
>>
>> Flow:
>>
>>- Calculate the TTL using response fetched time and max-age header
>>- Set the Age header to the cached response before returning it to
>>

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

[Shazni Nazeer]

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 cached response, make
>a request with "If-None-Match" header with the ETag value.
>
>
>- If the server returns "304 Not Modified" response returns the cached
>response to the user.
>
> 2. If the caller makes a request with "If-None-Match" header with the ETag
value and if it matched, why would you need to respond with the cached
message. Shouldn't it be only 304 with empty message as the response hasn't
changed?


> *Honor "max-age" cache-control header*If the "max-age" header presents in
> the response it specifies the maximum time in seconds that the fetched
> response is allowed to be reused from the time of the request. So the
> response should be cached and reused within the max-age time limit. So the
> Cache mediator should honor max-age instead of timeout configuration if it
> is less than the timeout configuration.


3. What is the behavior when the timeout configuration is less than the
max-age cache-control header?

On Thu, Jan 11, 2018 at 3:20 AM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> 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
> mediator with the following features:
>
>- Honor ETag header
>- Honor "no-cache" & "no-store" cache-control header.
>- Honor "max-age" cache-control header.
>- Add Age header based on "max-age" cache-control header when
>returning the cached response.
>
>
> *1. ETag support:*
> If ETag header is present in the response, subsequent requests need to be
> issued with the "If-None-Match" header(with ETag value) and if the
> requested resource is modified from the last response fetched time, a new
> modified response will be returned with new ETag. And this new response
> needs to be cached. If it is not modified, the server returns a "304 Not
> Modified" response. In that case, the cached response can be reused.
>
> Flow:
>
>- Cache mediator receives a request.
>- Check whether a cached response is available for the same request.
>- If it is available and ETag is present in the cached response, make
>a request with "If-None-Match" header with the ETag value.
>- If the server returns "304 Not Modified" response returns the cached
>response to the user.
>- If the server returns a new modified response(200 OK response) then
>cache the newly returned response.
>
>
> *2. Honor "no-cache" and "no-store" header*
>
>- If the "no-cache" header is present in the response it indicates
>that the returned response can’t be used to satisfy a subsequent request to
>the same URL without first checking with the server if the response has
>changed. So before responding with the cached response cache mediator
>should validate the response with ETag. This can be supported through the
>ETag support.
>- If the "no-store" header is present in the response, Cache mediator
>should not cache the returned response.
>
> *3. Honor "max-age" cache-control header*
> If the "max-age" header presents in the response it specifies the maximum
> time in seconds that the fetched response is allowed to be reused from the
> time of the request. So the response should be cached and reused within the
> max-age time limit. So the Cache mediator should honor max-age instead of
> timeout configuration if it is less than the timeout configuration.
>
> 4. *Include an ‘Age’ header with the response*
> Cache mediator should return the true TTL value of a response without
> altering the value of the cache-control max-age header returned by the
> back-end.
>
>
> Flow:
>
>- Calculate the TTL using response fetched time and max-age header
>- Set the Age header to the cached response before returning it to the
>user.
>
>
> [1]. https://developers.google.com/web/fundamentals/
> performance/optimizing-content-efficiency/http-caching
> [2]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
> Thanks,
> Keerthika.
> --
> 
> Keerthika Mahendralingam
> Software Engineer
> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
> keerth...@wso2.com
> WSO2, Inc.
> lean . enterprise . middleware
>



-- 
Shazni Nazeer

Mob : +94 37331
LinkedIn : http://lk.linkedin.com/in/shazninazeer

Blogs :

https://medium.com/@mshazninazeer
http://shazninazeer.blogspot.com


___
Architecture mailing list
Architecture@wso2.org

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

[Keerthika Mahendralingam]

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
mediator with the following features:

   - Honor ETag header
   - Honor "no-cache" & "no-store" cache-control header.
   - Honor "max-age" cache-control header.
   - Add Age header based on "max-age" cache-control header when returning
   the cached response.


*1. ETag support:*
If ETag header is present in the response, subsequent requests need to be
issued with the "If-None-Match" header(with ETag value) and if the
requested resource is modified from the last response fetched time, a new
modified response will be returned with new ETag. And this new response
needs to be cached. If it is not modified, the server returns a "304 Not
Modified" response. In that case, the cached response can be reused.

Flow:

   - Cache mediator receives a request.
   - Check whether a cached response is available for the same request.
   - If it is available and ETag is present in the cached response, make a
   request with "If-None-Match" header with the ETag value.
   - If the server returns "304 Not Modified" response returns the cached
   response to the user.
   - If the server returns a new modified response(200 OK response) then
   cache the newly returned response.


*2. Honor "no-cache" and "no-store" header*

   - If the "no-cache" header is present in the response it indicates that
   the returned response can’t be used to satisfy a subsequent request to the
   same URL without first checking with the server if the response has
   changed. So before responding with the cached response cache mediator
   should validate the response with ETag. This can be supported through the
   ETag support.
   - If the "no-store" header is present in the response, Cache mediator
   should not cache the returned response.

*3. Honor "max-age" cache-control header*
If the "max-age" header presents in the response it specifies the maximum
time in seconds that the fetched response is allowed to be reused from the
time of the request. So the response should be cached and reused within the
max-age time limit. So the Cache mediator should honor max-age instead of
timeout configuration if it is less than the timeout configuration.

4. *Include an ‘Age’ header with the response*
Cache mediator should return the true TTL value of a response without
altering the value of the cache-control max-age header returned by the
back-end.


Flow:

   - Calculate the TTL using response fetched time and max-age header
   - Set the Age header to the cached response before returning it to the
   user.


[1].
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
[2]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Thanks,
Keerthika.
--

Keerthika Mahendralingam
Software Engineer
Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
keerth...@wso2.com
WSO2, Inc.
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture