Search squid archive

Re: Re: acl defined with rep_header used to deny cache is not working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux