[squid-users] Caching http google deb files

[Hardik Dangar]

Wow, i couldn't think about that. google might need tracking data that
could be the reason they have blindly put vary * header. oh Irony, company
which talks to all of us on how to deliver content is trying to do such
thing.

I have looked at your patch but how do i enable that ? do i need to write
custom ACL ? i know i need to compile and reinstall after applying patch
but what do i need to do exactly in squid.conf file as looking at your
patch i am guessing i need to write archive acl or i am too naive to
understand C code :)

Also

reply_header_replace is any good for this ?


On Tue, Oct 4, 2016 at 7:47 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 5/10/2016 2:34 a.m., Hardik Dangar wrote:
> > Hey Amos,
> >
> > We have about 50 clients which downloads same google chrome update every
> 2
> > or 3 days means 2.4 gb. although response says vary but requested file is
> > same and all is downloaded via apt update.
> >
> > Is there any option just like ignore-no-store? I know i am asking for too
> > much but it seems very silly on google's part that they are sending very
> > header at a place where they shouldn't as no matter how you access those
> > url's you are only going to get those deb files.
>
>
> Some things G does only make sense whan you ignore all the PR about
> wanting to make the web more efficient and consider it's a company whose
> income is derived by recording data about peoples habits and activities.
> Caching can hide that info from them.
>
> >
> > can i hack squid source code to ignore very header ?
> >
>
> Google are explicitly saying the response changes. I suspect there is
> something involving Google account data being embeded in some of the
> downloads. For tracking, etc.
>
>
> If you are wanting to test it I have added a patch to
> <http://bugs.squid-cache.org/show_bug.cgi?id=4604> that should implement
> archival of responses where the ACLs match. It is completely untested by
> me beyond building, so YMMV.
>
> Amos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161004/c8f5f081/attachment.html>