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