On 14/04/2014 10:50 p.m., Jasper Van Der Westhuizen wrote:
>
>>> refresh_pattern -i pack.google.com/.*\.(exe|crx) 10080 80% 43200
>>> override-expire override-lastmod ignore-no-cache ignore-reload
>>> reload-into-ims ignore-private
>>>
>>> I see the following behavior in my logs. This is for the same
>>> client(source). Multiple entries, like it gets downloaded over and over
>>> again.
>>> Logs:
>>>
>>> 1397459574.511 199 xxx.xxx.xxx.xxx TCP_MISS/302 1400 GET
>>> http://cache.pack.google.com/edgedl/chrome/win/34.0.1847.116_33.0.1750.154_chrome_updater.exe - DEFAULT_PARENT/xxx.xxx.xxx.xxx text/html
>>> 1397459579.924 4794 xxx.xxx.xxx.xxx TCP_MISS/206 141330 GET
>>> http://r2---sn-pn-woce.c.pack.google.com/edgedl/chrome/win/34.0.1847.116_33.0.1750.154_chrome_updater.exe? - DEFAULT_PARENT/xxx.xxx.xxx.xxx application/x-msdos-program
>>> 1397459591.067 548 xxx.xxx.xxx.xxx TCP_MISS/302 1400 GET
>>> http://cache.pack.google.com/edgedl/chrome/win/34.0.1847.116_33.0.1750.154_chrome_updater.exe - DEFAULT_PARENT/xxx.xxx.xxx.xxx text/html
>>> 1397459596.709 4917 xxx.xxx.xxx.xxx TCP_MISS/206 283744 GET
>>> http://r2---sn-pn-woce.c.pack.google.com/edgedl/chrome/win/34.0.1847.116_33.0.1750.154_chrome_updater.exe? - DEFAULT_PARENT/xxx.xxx.xxx.xxx
>>> application/x-msdos-program
>>>
>>> Is my refresh pattern incorrect?
>>>
>> Dag se Jasper :)
>>
>> Should it not read *pack.google....
>>
>> Cheers,
>>
>> Pieter
>>
>
> Hi Pieter
>
> No, that gives me an incorrect regular expression error.
NP: regex has an implied .* prefix and suffix on patterns unless you use
the ^ and $ endpoint anchors.
What are the HTTP headers for these requests and replies?
The 206 status indicates a Range request taking place. But the first
and third log entry indicate a 283KB range out of a 1400 byte rediretion
object being delivered. But weird.
A quick scan by redbot indicates that the top URL is a redirection (302
as logged first but not second time around) to a URL which responds with
the worlds most annoying Vary header.
"Vary: * effectively makes this response uncacheable." in redbots words.
Amos
Received on Mon Apr 14 2014 - 12:04:45 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 15 2014 - 12:00:09 MDT