> > > 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected]> wrote: >>> >>>> +1. Thanks Riyafa for the suggestion. >>>> >>>> >>>> Thanks, >>>> Keerthika. >>>> >>>> On Fri, Jan 12, 2018 at 3:05 PM, Riyafa Abdul Hameed <[email protected]> >>>> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Sanjeewa, >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 12:01 PM, Sanjeewa Malalgoda < >>>>>>> [email protected]> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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/performa >>>>>>>>>>>> nce/optimizing-content-efficiency/http-caching >>>>>>>>>>>> [2]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Keerthika. >>>>>>>>>>>> -- >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> Keerthika Mahendralingam >>>>>>>>>>>> Software Engineer >>>>>>>>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>>>>>>>> [email protected] >>>>>>>>>>>> WSO2, Inc. >>>>>>>>>>>> lean . enterprise . middleware >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Shazni Nazeer >>>>>>>>>>> >>>>>>>>>>> Mob : +94 777737331 >>>>>>>>>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>>>>>>>>>> >>>>>>>>>>> Blogs : >>>>>>>>>>> >>>>>>>>>>> https://medium.com/@mshazninazeer >>>>>>>>>>> http://shazninazeer.blogspot.com >>>>>>>>>>> >>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> <[email protected]> >>>>>>>>>> Keerthika Mahendralingam >>>>>>>>>> Software Engineer >>>>>>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>>>>>> [email protected] >>>>>>>>>> WSO2, Inc. >>>>>>>>>> lean . enterprise . middleware >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Isuru Udana* >>>>>>>>> Senior Technical Lead >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> email: [email protected] cell: +94 77 3791887 <077%20379%201887> >>>>>>>>> blog: http://mytecheye.blogspot.com/ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Sanjeewa Malalgoda* >>>>>>>> WSO2 Inc. >>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>> >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vijitha Ekanayake >>>>>>> Senior Software Engineer*, *WSO2, Inc.; http://wso2.com/ >>>>>>> Mobile : +94 777 24 73 39 | +94 718 74 44 08 >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> <[email protected]> >>>>>> Keerthika Mahendralingam >>>>>> Software Engineer >>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>> [email protected] >>>>>> WSO2, Inc. >>>>>> lean . enterprise . middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Riyafa Abdul Hameed >>>>> Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> >>>>> >>>>> Email: [email protected] <[email protected]> >>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >>>>> <http://twitter.com/Riyafa1> >>>>> >>>> >>>> >>>> >>>> -- >>>> <[email protected]> >>>> Keerthika Mahendralingam >>>> Software Engineer >>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>> [email protected] >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> >>> >>> >>> >>> -- >>> Dushan Abeyruwan | Architect >>> Technical Support,MV >>> PMC Member Apache Synpase >>> WSO2 Inc. http://wso2.com/ >>> Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* >>> LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan >>> <https://www.linkedin.com/in/dushanabeyruwan>* >>> Mobile:(001)408-791-9312 <+1%20408-791-9312> >>> >>> >> >> >> -- >> Riyafa Abdul Hameed >> Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> >> >> Email: [email protected] <[email protected]> >> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >> <http://twitter.com/Riyafa1> >> > > > > -- > Dimuthu Leelarathne > Director, Solutions Architecture > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile: +94773661935 <+94%2077%20366%201935> > Blog: http://muthulee.blogspot.com > > Lean . Enterprise . Middleware > -- <[email protected]> Keerthika Mahendralingam Software Engineer Mobile :+94 (0) 776 121144 [email protected] WSO2, Inc. lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
