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_curren >>> 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.google. >>> 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
