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 <[email protected]> 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 < > [email protected]> 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 <[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 <+94%2077%20612%201144> >> [email protected] >> WSO2, Inc. >> lean . enterprise . middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Malaka. > -- > Malaka Gangananda - Software Engineer | WSO2 > Email : [email protected] > Mobile : +94713564340 <+94%2071%20356%204340> > Web : http://wso2.com > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- <[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
