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 [email protected] WSO2, Inc. lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
