+1. Thanks Riyafa for the suggestion.
Thanks, Keerthika. On Fri, Jan 12, 2018 at 3:05 PM, Riyafa Abdul Hameed <riy...@wso2.com> 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 <isu...@wso2.com> 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 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. >>>>>>>> -- >>>>>>>> <dev-requ...@wso2.org> >>>>>>>> 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 777737331 >>>>>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>>>>>> >>>>>>> Blogs : >>>>>>> >>>>>>> https://medium.com/@mshazninazeer >>>>>>> http://shazninazeer.blogspot.com >>>>>>> >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> <dev-requ...@wso2.org> >>>>>> Keerthika Mahendralingam >>>>>> Software Engineer >>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>> keerth...@wso2.com >>>>>> WSO2, Inc. >>>>>> lean . enterprise . middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Isuru Udana* >>>>> Senior Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> email: isu...@wso2.com 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 >>> >> >> >> >> -- >> <dev-requ...@wso2.org> >> Keerthika Mahendralingam >> Software Engineer >> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >> keerth...@wso2.com >> WSO2, Inc. >> lean . enterprise . middleware >> > > > > -- > Riyafa Abdul Hameed > Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> > > Email: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> > Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> > <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> > <http://twitter.com/Riyafa1> > -- <dev-requ...@wso2.org> Keerthika Mahendralingam Software Engineer Mobile :+94 (0) 776 121144 keerth...@wso2.com WSO2, Inc. lean . enterprise . middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
