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
