[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi
Garri Djavadyan
garryd at comnet.uz
Mon Oct 24 14:40:07 UTC 2016
On Tue, 2016-10-25 at 01:22 +1300, Amos Jeffries wrote:
> On 25/10/2016 12:32 a.m., Garri Djavadyan wrote:
> >
> > On Mon, 2016-10-24 at 23:51 +1300, Amos Jeffries wrote:
> > >
> > > On 24/10/2016 9:59 p.m., Garri Djavadyan wrote:
> > > >
> > > > Nevertheless, the topic surfaced new details regarding the Vary
> > > > and
> > > > I
> > > > tried conditional requests on same URL (Google Chrome) from
> > > > different
> > > > machines/IPs. Here results:
> > > >
> > > > $ curl --head --header "If-Modified-Since: Thu, 22 Oct 2016
> > > > 08:29:09
> > > > GMT" https://dl.google.com/linux/direct/google-chrome-stable_cu
> > > > rren
> > > > t_am
> > > > d64.deb
> > > > HTTP/1.1 304 Not Modified
> > > > Etag: "101395"
> > > > Server: downloads
> > > > Vary: *
> > > > X-Content-Type-Options: nosniff
> > > > X-Frame-Options: SAMEORIGIN
> > > > X-Xss-Protection: 1; mode=block
> > > > Date: Mon, 24 Oct 2016 08:53:44 GMT
> > > > Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
> > > >
> > > > ----
> > > >
> > > > $ curl --head --header 'If-None-Match: "101395"' https://dl.goo
> > > > gle.
> > > > com/
> > > > linux/direct/google-chrome-stable_current_amd64.deb
> > > > HTTP/1.1 304 Not Modified
> > > > Etag: "101395"
> > > > Last-Modified: Thu, 20 Oct 2016 08:29:09 GMT
> > > > Server: downloads
> > > > Vary: *
> > > > X-Content-Type-Options: nosniff
> > > > X-Frame-Options: SAMEORIGIN
> > > > X-Xss-Protection: 1; mode=block
> > > > Date: Mon, 24 Oct 2016 08:54:18 GMT
> > > > Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
> > > >
> > >
> > > Sweet! Far better than I was expecting. That means this patch
> > > should
> > > work:
> > >
> > > === modified file 'src/http.cc'
> > > --- src/http.cc 2016-10-08 22:19:44 +0000
> > > +++ src/http.cc 2016-10-24 10:50:16 +0000
> > > @@ -593,7 +593,7 @@
> > > while (strListGetItem(&vary, ',', &item, &ilen, &pos)) {
> > > SBuf name(item, ilen);
> > > if (name == asterisk) {
> > > - vstr.clear();
> > > + vstr = asterisk;
> > > break;
> > > }
> > > name.toLower();
> > > @@ -947,6 +947,12 @@
> > > varyFailure = true;
> > > } else {
> > > entry->mem_obj->vary_headers = vary;
> > > +
> > > + // RFC 7231 section 7.1.4
> > > + // Vary:* can be cached, but has mandatory
> > > revalidation
> > > + static const SBuf asterisk("*");
> > > + if (vary == asterisk)
> > > + EBIT_SET(entry->flags, ENTRY_REVALIDATE_ALWAYS);
> > > }
> > > }
> > >
> > >
> > > Amos
> >
> > I have applied the patch. Below my results.
> >
> > In access.log I see:
> >
> > 1477307991.672 49890 127.0.0.1 TCP_REFRESH_MODIFIED/200 45532786
> > GET h
> > ttp://dl.google.com/linux/direct/google-chrome-
> > stable_current_amd64.deb
> > - HIER_DIRECT/173.194.222.136 application/x-debian-package
> >
> > In packet capture, I see that Squid doesn't use conditional
> > request:
> >
> > GET /linux/direct/google-chrome-stable_current_amd64.deb HTTP/1.1
> > User-Agent: curl/7.50.3
> > Accept: */*
> > Host: dl.google.com
> > Via: 1.1 gentoo.comnet.uz (squid/3.5.22)
> > X-Forwarded-For: 127.0.0.1
> > Cache-Control: max-age=259200
> > Connection: keep-alive
>
> Hmmm. That looks to me like the new patch is working (log says
> REFRESH
> being done) but there is some bug in the revalidate logic not adding
> the
> required headers.
> If thats right, then that bug might be causing other revalidate
> traffic
> to have major /200 issues.
>
> I'm in need of sleep right now. If you can grab a ALL,9 cache.log
> trace
> and mail it to me I will take a look in the morning. Otherwise I will
> try to replicate the case myself and track it down in the next few
> days.
>
> Amos
Sorry, I probably analysed the header of first request. I tried again,
and found that Squid sends the header correctly:
GET /linux/direct/google-chrome-stable_current_amd64.deb HTTP/1.1
If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT
If-None-Match: "101395"
User-Agent: curl/7.50.3
Accept: */*
Host: dl.google.com
Via: 1.1 gentoo.comnet.uz (squid/3.5.22)
X-Forwarded-For: 127.0.0.1
Cache-Control: max-age=259200
Connection: keep-alive
Sad enough, the reply is:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: application/x-debian-package
ETag: "101395"
Last-Modified: Thu, 20 Oct 2016 08:29:09 GMT
Server: downloads
Vary: *
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Date: Mon, 24 Oct 2016 13:41:13 GMT
Content-Length: 45532350
Connection: keep-alive
So, the big G sends 304 only to HEAD requests, although it is a
violation [1], AIUI:
curl --head -H 'If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT' -H
'If-None-Match: "101395"' http://dl.google.com/linux/direct/google-chro
me-stable_current_amd64.deb
HTTP/1.1 304 Not Modified
ETag: "101395"
Server: downloads
Vary: *
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Date: Mon, 24 Oct 2016 14:36:32 GMT
Connection: keep-alive
---
$ curl --verbose -H 'If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT'
-H 'If-None-Match: "101395"' http://dl.google.com/linux/direct/google-c
hrome-stable_current_amd64.deb > /dev/null
> GET /linux/direct/google-chrome-stable_current_amd64.deb HTTP/1.1
> Host: dl.google.com
> User-Agent: curl/7.50.3
> Accept: */*
> If-Modified-Since: Thu, 20 Oct 2016 08:29:09 GMT
> If-None-Match: "101395"
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Type: application/x-debian-package
< ETag: "101395"
< Last-Modified: Thu, 20 Oct 2016 08:29:09 GMT
< Server: downloads
< Vary: *
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< Date: Mon, 24 Oct 2016 14:38:19 GMT
< Content-Length: 45532350
< Connection: keep-alive
[1] https://tools.ietf.org/html/rfc7234#section-4.3.5
Garri
More information about the squid-users
mailing list