Re: [squid-users] I want to verify why squid wont cache a specific object.

On 20.08.2012 11:37, Eliezer Croitoru wrote:
> On 8/20/2012 1:38 AM, Amos Jeffries wrote:
>>
>> The FFFFFFFF is the file number/name where it is being stored. Since
>> this is an erased operation that is always the magic F value.
>>
>> It is not 1-to-1 related to the object being cacheable. It just
>> means
>> the object *currently* stored needs removing. Non-cacheable objects
>> the
>> RELEASE immediately follows storage, for cacheable objects being
>> replaced the erase of old content immediately follows storage of new
>> copies.
> OK
>>
>>
>> Since the caching changes between UA. I would assume the player is
>> sending some form of no-cache or no-store control in the request
>> headers. Set debug section 11,2 if you can and find the players
>> request
>> headers.
> I have reviewed the headers before using wireshark\tcpdump but
> couldn't find anything in them that suppose to change the behavior to
> the object.
>
> anyway the headers from the debug section are:
> ##start
> 2012/08/20 02:00:43.682 kid1| HTTP Client local=54.240.162.191:80
> remote=192.168.10.100:60900 FD 32 flags=33
> 2012/08/20 02:00:43.682 kid1| HTTP Client REQUEST:
> ---------
> GET
>
> /MV5BMTUwMDMzOTQ4MF5BMTFeQW1wNF5BbWU3MDY0MzUzOTQ@.mp4?Expires=1345449755&Signature=igqZatNciNUeCPcPTDUIBC2oX4BN7A1Go5U5h6BHeUo2z0qXyKl~1LQo1MHb8KnVmSob1GSlNs3LAbVuTSCQxSV3FfBBPH~~09CIoIFfZE7lDkBzXcjYBMC757-1OLP1eHHx5TmPNv00dBuoMCN90xlu~uifWzgsYbFNSaQans8_&Key-Pair-Id=APKAILW5I44IHKUN2DYA&hint=flv
> HTTP/1.1
> Host: video-http.media-imdb.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0)
> Gecko/20100101 Firefox/13.0
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Referer: http://www.imdb.com/images/js/jwplayer/5.9/player.swf
> ##end
>
> this is issued by the browser:
> ##start
> 2012/08/20 02:15:25.088 kid1| HTTP Client local=54.240.162.174:80
> remote=192.168.10.100:64245 FD 24 flags=33
> 2012/08/20 02:15:25.088 kid1| HTTP Client REQUEST:
> ---------
> GET
>
> /MV5BMTUwMDMzOTQ4MF5BMTFeQW1wNF5BbWU3MDY0MzUzOTQ@.mp4?Expires=1345450432&Signature=PCnHMyiuodLmW-r1toSrSa7Gs~bJa7Io05AOBksCMCT5HNI2MYYPWtdyHM5W~5N4RtUSaY9SVzU4OlsSpSzGPZG0BD5nvP3RXIv03PqHMUQQo-lzASOC6TY1R3ARrVwgEm5mn3BrRQ4Ce6dwC7x9eGH~XgFNrKqcJCFxmbTwxQ8_&Key-Pair-Id=APKAILW5I44IHKUN2DYA&hint=flv
> HTTP/1.1
> Host: video-http.media-imdb.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0)
> Gecko/20100101 Firefox/13.0
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> If-Modified-Since: Wed, 13 Apr 2011 17:18:18 GMT
> If-None-Match: "c9164ada101ce1baad52740ec34b2027"
> ##end
>
> and this is the response:
> ##start
> ---------
> HTTP/1.1 304 Not Modified
> Date: Sun, 19 Aug 2012 23:17:19 GMT
> ETag: "c9164ada101ce1baad52740ec34b2027"
> Last-Modified: Wed, 13 Apr 2011 17:18:18 GMT
> Age: 47447
> X-Cache: Hit from cloudfront
> X-Amz-Cf-Id: LnmQ_CfVeSreDlbL_vz0gFVPGkRuy5O6ajlxmfsoBjdAUkcn6ff3zw==
> X-Cache: MISS from proxy
> Via: 1.0 add6ceb4822d467e68d27b0dbaa26dae.cloudfront.net
> (CloudFront), 1.1 proxy (squid/3.2.1)
> Connection: keep-alive
> ##end

Two possibilities:

1) Did you bump up the maximum_object_size? default being 4MB and these
objects are ~16MB.

2) They are dynamic objects without any Cache-Control or Expires header
to explicitly state the cacheability age. That means they fall under the
"risky" category which is set to a 0 maximum age by the default '?'
refresh pattern.

Amos
Received on Mon Aug 20 2012 - 00:45:56 MDT