Re: [squid-users] adobe updates constantly re-downloading

On 29/05/2013 10:33 p.m., Marko Cupać wrote:
> On Wed, 29 May 2013 21:08:58 +1200
> Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>
>> On 29/05/2013 7:18 p.m., Marko Cupać wrote:
>>> On Wed, 15 May 2013 21:36:51 +0800
>>> csn233 <csn233_at_gmail.com> wrote:
>>>
>>>> Have you tried commenting out range_offset_limit and quick_abort_min?
>>> Sorry for my late reply. In the meantime i upgraded to squid-3.3.4_1,
>>> which did not solve the problem. But then I remembered your suggestion,
>>> and removed range_offset_limit and quick_abort_min. Updates from adobe
>>> are now downloaded fine (no constant re-downloading without ever
>>> finishing), but not cached.
>>>
>>> It is not such a big problem as my uplinks are can handle those.
>>> However, saving some bandwidth would be nice, so if someone knows how
>>> to do it please send a line.
>> Do you have or able to get a copy of the request and reply headers
>> between Squid and the Adobe servers for these transactions. That will
>> help determine what Squid is doing or able to do with them.
>>
>> In 3.3 you can set "debug_options 11,2" to obtain a cache.log trace of
>> the HTTP headers going through Squid. (may produce big logs on a busy
>> proxy).
>>
>> Amos
> I turned it on for a few minutes and completed download. Then, after
> some time I repeated it just to check if it was cached, but it was
> not.
> Log is really huge so I am sending just relevant parts (the ones
> related to adobe).

That seems fine for now.

What I can see in there is two types of request going through.
1) requests for .../message.zip which is a short lifetime object
  - its cacheable, but appears to be cached by the client browser and
Squid is just left with relaying the tiny REFRESH transactions back and
forward. Which is fine.

2) requests for a .exe which is the large 33MB update.
  - from the headers it looks completely cacheable which means a bug or
config problem somewhere in Squid preventing the response being cached.
Looks like an audit of the cacheability and age code is in order to
figure this one out better. :-(

Amos
Received on Wed May 29 2013 - 13:08:55 MDT