Hi Keerthika, As Shazni mentioned this is a very useful addition to the cache mediator functionality. I believe the suggested Cache mediator modifications compliant with RFC-2616[1]. i.e. wherever the specification shows MUST, MUST NOT, SHOULD, or SHOULD NOT for HTTP caches, the cache mediator endeavors to carry on in a way that fulfills those necessities. With that, the end user has the assurance of adding cache mediator won't produce any incorrect behavior.
Additionally, Shall we provide a configurations option to ignore the HTTP Caching headers on the off chance that somebody isn't interested in HTTP caching functionality? WDYT? [1]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Thanks. On Fri, Jan 12, 2018 at 9:27 AM, Shazni Nazeer <[email protected]> wrote: > This is a very useful addition. ETag header is particularly useful. > > I have a few questions. > > 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 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? > > >> *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? > > 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> > -- Vijitha Ekanayake Senior Software Engineer*, *WSO2, Inc.; http://wso2.com/ Mobile : +94 777 24 73 39 | +94 718 74 44 08 lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
