On 09/10/2018 09:03 AM, Hariharan Sethuraman wrote: > 1) ok, the client does a GET /<resource> with authorization header. So I > cant cache unless I ask the site-owner to send the cache-control to > whatever it can enable the intermediate cache-server to persist it. > 2) Does squid-cache allow a way where I can upload the file into cache? You may have one or two Squid-related options AFAICT: 1. Configure Squid to remove the authentication headers going to the origin server (see request_header_access). If the origin server does not actually require authentication for this specific resource, then Squid will get a cachable response back. Assuming the server is not broken, this approach is safe. However, this approach will _not_ work if the server requires authentication for this resource. 2. Configure Squid to (use an adaptation service to) add Cache-Control response headers that would allow Squid to cache the authenticated response. Adding response headers pre-cache probably requires using an adaptation service -- Squid itself does not have a directive that would add response headers before the response is evaluated for cachability (reply_header_access is a post-cache directive so it will not work here). This approach should "work" regardless of the server behavior. As Amos has said, this approach is _unsafe_ -- you may cache and share a response with user-specific info in it. You should not do this unless you are absolutely sure that the response is safe to share! Changing the origin server behavior is the best option if it is available to you. Alex. > On Mon, Sep 10, 2018 at 8:21 PM Amos Jeffries wrote: > > On 11/09/18 2:27 AM, Hariharan Sethuraman wrote: > > > > On Mon, 10 Sep 2018, 19:46 Amos Jeffries wrote: > > > > On 11/09/18 12:18 AM, Hariharan Sethuraman wrote: > > > > > > 2) With more debug_options enabled, I see that it is not caching > > because > > > the response is part of authenticated flow. Is there a way I can > > > override this? > > > > No. The server is supplying sufficient headers for caching to > make it > > appear that the site authors intentionally are sending what > does get > > delivered. > > > > If I understand correctly, you are saying the caching will not be done > > on squid as the content is authorised by the specific client. We can't > > Authenticated, not authorized. This is one place where the difference > matters. > > > do anything until I ask site owners to change cache control as public? > > > > Pretty much, yes. I know Chrome at least used to deliver binaries whose > installer contained details of the Google account of the user fetching > it. So its not very safe to assume even downloaders are safely > transferable. > > Amos > > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
