[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

Yuri yvoinov at gmail.com
Mon Oct 24 15:19:56 UTC 2016


I'm sorry to interrupt - I remember someone saying that you need to 
always abide by RFC? Well, as you say it to Google?


24.10.2016 20:40, Garri Djavadyan пишет:
> 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
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users



More information about the squid-users mailing list