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 blog: http://mytecheye.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
