<div dir="ltr"><div>Thanks a lot Amos.</div><div><br></div>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.<div>2) Does squid-cache allow a way where I can upload the file into cache?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 10, 2018 at 8:21 PM Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 make it<br>
>     appear that the site authors intentionally are sending what 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 transferable.<br>
<br>
Amos<br>
</blockquote></div>