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
