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

On 20.08.2012 10:10, Eliezer Croitoru wrote:
> I have been checking out about IMDB videos and it seems like the
> original requests cannot be cached from an unknown reason.
>
> the store log shows:
> 1345335832.436 RELEASE -1 FFFFFFFF B174D16A30640884673D882B55B3594C
> 200 1334135877 1302715098 -1 video/mp4 16586249/16586249 GET
>
> http://video-http.media-imdb.com/MV5BMTUwMDMzOTQ4MF5BMTFeQW1wNF5BbWU3MDY0MzUzOTQ@.mp4?Expires=1345368308&Signature=Q2dXbWeH4jZXddLAPgOxKrrgbzbuBGZSha5OU4muOH68UFaJ-MlxMUbqbocmzzsSpEJA23aTW46tDlm18RSGzuSiIQgi4tf3lchNMV2hSdDaHqGHrIHVmGWnGCW7VWFfOcYihdM3MqU9EpjO4qzrfoi95cKRXBc~SFCQR4gC8jM_&Key-Pair-Id=APKAILW5I44IHKUN2DYA&hint=flv
>
> and it means that the file cannot be cached by squid.
> It's weird a bit because I did some tracking on the connection and
> requests but dosnt seems to get the full picture of why it will not
> be
> cached.
>
> The video will be cached if i will do a regular request from a
> browser wget or other means but not the original player.
>
> The request is a simple GET with a full size response as stated in
> the headers all fit the criteria of cachable object.
>
> this is the response headers:
> ##start
> HTTP/1.1 200 OK
> x-amz-id-2: blabla/AIBT0KwY/mC1f2mnZx0crlLcLUcdYqxt7
> x-amz-request-id: E903CD06E96673AC
> Date: Wed, 11 Apr 2012 09:17:57 GMT
> Last-Modified: Wed, 13 Apr 2011 17:18:18 GMT
> ETag: "c9164ada101ce1baad52740ec34b2027"
> Accept-Ranges: bytes
> Content-Type: video/mp4
> Content-Length: 16586249
> Server: AmazonS3
> Age: 48065
> X-Cache: Hit from cloudfront
> X-Amz-Cf-Id: blabla_SZfHBxHjWxZvaw==
> X-Cache: MISS from proxy1
> X-Cache: MISS from proxy2
> Via: 1.0 dd9f0ef9e10a3156b506f6324ccd2e2a.cloudfront.net
> (CloudFront), 1.1 proxy2 (squid/3.2.1), 1.1 proxy1 (squid/3.2.1)
> Connection: keep-alive
> ##end
>
> I dont know what debug sections to even look at.
> like is there a sections that shows the reason for an object to be a
> FFFFFFFF type ?

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.

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.

Amos
Received on Sun Aug 19 2012 - 22:38:30 MDT