On 14/11/2013 1:13 a.m., susu wrote: > I am posting the headers of three request and responses. Last request starts > video streaming, Pragma: xPlayStrm=1 asks the server to start video > streaming. Thank you. These look like they should be working without problems, even if a cache is present. There is one possible problem though if you happen to be one of the proxies with a refresh_pattern involving .asf or .wmv and overriding cace controls to enforce explicit long-term storage of the video objects. > > GET http://10.102.78.163/Police_1234.wmv?MSWMExt=.asf HTTP/1.1 > Cache-Control: no-cache * Client requests that HTTP/1.1 compliant caches ignore any stored data and request a new version from the origin server. > Pragma: getIfoFileURI.dlna.org > Accept: */* > User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514 > GetContentFeatures.DLNA.ORG: 1 > Connection: Keep-Alive > Host: 10.102.78.163 > > > HTTP/1.1 200 OK > Content-Type: video/x-ms-wvx > Cache-Control: max-age=0, no-cache * server indicates that the object may be stored by any HTTP/1.1 compliant cache, BUT that it must be considered stale already and re-validated before delivering to any other client. > Server: Cougar/9.6.7600.16564 > Content-Length: 128 > Date: Mon, 26 Aug 2013 05:08:52 GMT > Pragma: no-cache, xResetStrm=1, timeout=60000 * server indicates that HTTP/1.0 (only) caches may not store this object. > Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, > com.microsoft.wm.predstrm, com.microsoft.wm.fastcache, > com.microsoft.wm.startupprofile > > > > ------------------------------------------------------------------ > > GET http://10.102.78.163/Police_1234.wmv?MSWMExt=.asf HTTP/1.0 > Host: 10.102.78.163 > User-Agent: NSPlayer/12.00.7601.17514 > Accept: */* > Accept-Language: en-us, *;q=0.1 > Connection: Keep-Alive > Pragma: xClientGuid={3300AD50-2C39-46C0-AE0A-A61641952D40} > Pragma: packet-pair-experiment=1 > Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, > com.microsoft.wm.startupprofile, com.microsoft.wm.predstrm > Pragma: > no-cache,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0 > Pragma: LinkBW=2147483647, rate=1.000, AccelDuration=10000, > AccelBW=2147483647 > * client requests the *same URL*. - HTTP/1.0 caches are requested to ignore any stored content they have and contact the origin server for a fresh copy. IMPROTANT: - HTTP/1.1 caches have no restrictions on what they can do > > HTTP/1.1 200 OK > Pragma: packet-pair-experiment=1, no-cache, client-id=397484926, > xResetStrm=1, features="seekable,stridable", timeout=60000 * server indicates that HTTP/1.0 (only) caches may not store this object. > Content-Type: application/vnd.ms.wms-hdr.asfv1 > Server: Cougar/9.6.7600.16564 > Content-Length: 8206 > Date: Mon, 26 Aug 2013 05:08:52 GMT > Cache-Control: no-cache, x-wms-content-size=1874716, max-age=4294967294, > user-public, must-revalidate, proxy-public, proxy-revalidate * server indicates that HTTP/1.1 compliant caches ARE allowed to store the response, BUT they MUST revalidate the content before delivering to any other clients (this revalidate requirement is repeated in 3 different ways). Additionally, the content is explicitly stated to be fresh in cache for up to 136 *years*. > Last-Modified: Tue, 30 Jul 2013 09:29:21 GMT > ETag: "1874716" > Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, > com.microsoft.wm.predstrm, com.microsoft.wm.fastcache, > com.microsoft.wm.startupprofile > Connection: keep-alive > > > > ------------------------------------------------------------------ > > GET http://10.102.78.163/Police_1234.wmv?MSWMExt=.asf HTTP/1.0 > Host: 10.102.78.163 > User-Agent: NSPlayer/12.00.7601.17514 > Accept: */* > Accept-Language: en-us, *;q=0.1 > Connection: Keep-Alive > Pragma: client-id=397484926 > Pragma: playlist-gen-id=157 > Pragma: xClientGuid={3300AD50-2C39-46C0-AE0A-A61641952D40} > Pragma: xPlayStrm=1 > Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, > com.microsoft.wm.startupprofile, com.microsoft.wm.predstrm > Pragma: > no-cache,stream-time=0,stream-offset=4294967295:4294967295,packet-num=4294967295,max-duration=0 > Pragma: playlist-seek-id=157 > Pragma: LinkBW=2147483647, rate=1.000, Speed=19.984, AccelDuration=10000, > AccelBW=2147483647 > Pragma: stream-switch-count=2 > Pragma: stream-switch-entry=ffff:1:0 ffff:2:0 > * client requests the *same URL*. - HTTP/1.0 caches are requested to ignore any stored content they have and contact the origin server for a fresh copy. IMPORTANT: - HTTP/1.1 caches have no restrictions on what they can do. > > HTTP/1.1 200 OK > Content-Type: application/x-mms-framed > Server: Cougar/9.6.7600.16564 > Date: Mon, 26 Aug 2013 05:08:53 GMT > Pragma: no-cache, client-id=397484926, features="seekable,stridable", > timeout=60000, AccelBW=3500000, AccelDuration=10000, Speed=5.000 * server indicates that HTTP/1.0 (only) caches may not store this object. > Cache-Control: no-cache, x-wms-content-size=1874716, max-age=4294967293, > user-public, must-revalidate, proxy-public, proxy-revalidate * server indicates that HTTP/1.1 compliant caches ARE allowed to store the response, BUT they MUST revalidate the content before delivering to any other clients (this revalidate requirement is repeated in 3 different ways). Additionally, the content is explicitly stated to be fresh in cache for up to 136 *years*. > Last-Modified: Tue, 30 Jul 2013 09:29:21 GMT > ETag: "1874716" LM header says the same timestamp for this reponse as previously. Additionally, and very importantly. The ETag unique per-object header *has not changed*. Indicating that this is the exact same response object as before. Although the headers are changing at each response. > X-StartupProfile: > Rate=10,12,15,20,30;MaxBytes=8979,6952,6163,5716,5716;Time=4733,133,133,0,0;StartTime=5000;LastTime=9799;MaxDiffTime=5503;MaxDiffSndTime=4164;ByteRate=18702,19778,19778,19778,19778; > Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, > com.microsoft.wm.predstrm, com.microsoft.wm.fastcache, > com.microsoft.wm.startupprofile > Connection: close > So... these requests and responses are explicitly permiting an HTTP/1.1 cache (such as Squid-3.1 and later) to store the video and serve it up to clients with only a revalidation to the server. I would presume to imagine that given teh strength with which they are trying to enforce the revalidate (as opposed to using the controls for enforcing non-storage) that the object *is* entirely cacheable and Squid is operating right. Amos
