Many thanks Alex, option 2 could work. Will check on security aspects. Thanks again to everyone.
On Mon, 10 Sep 2018, 21:11 Alex Rousskov, <rouss...@measurement-factory.com> wrote: > 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@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > > > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
