Hey susu,
In order to deny these problems due to Microsoft or any intermediate
http cache instructions you can use the "cache deny acl" format.
For the example:
GET http://10.102.78.163/Police_1234.wmv?MSWMExt=.asf HTTP/1.0
I can say that the origin server is 10.102.78.163 and the file has some
url identity.
These can be used to deny the caching explicitly using a set of rules:
##START
acl server dstdom_regex 10\.102\.78\.163
acl videos urlpath_regex [-i] \.(wmv|asf|asx)
cache deny server videos
cache allow all
##END
The above rules will apply a forcibly denial of the urls from only this
server and the path contains dot wmv\asf\asx first hits.
Since there must be a way to actually cache good responses for HTTP
clients I am not sure who causes this issue yet(ms or others).
But I do know as a fact for most update services of microsoft to at
least appear as very Cache friendly else then the 206 responses which
can also be considered as bandwidth friendly.
Hope it helps you,
Eliezer
On 13/11/13 13:44, susu wrote:
Hi Amos,
Thank you for your reply.
This is required because when a video is hosted in windows media server and
fetched from client using windows media player it uses Windows media HTTP
streaming protocol for video streaming.
In this protocol client sends 2-3 subsequent requests to the sever to fetch
the video with same url using some pragmas. If the video is present in
cache, squid is serving all the requests with the cached data i.e. the video
file. This is creating problem. To avoid this scenario I don't want to cache
any response from windows media server.
susu
