[squid-users] Squid 4.2 : caching is not working

[Hariharan Sethuraman]

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, <rousskov at 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 at lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users
> >
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180910/4988d390/attachment.html>