Re: [squid-users] Whis this dosn't cache?? Found something

found in the ALL,5 logs:
2013/07/03 10:56:45.070 kid1| store.cc(459) destroyMemObject:
destroyMemObject 0x7f3179ad3b70
2013/07/03 10:56:45.070 kid1| MemObject.cc(111) ~MemObject: del
MemObject 0x7f3179ad3b70
2013/07/03 10:56:45.071 kid1| HttpRequest.cc(695) storeId: sent back
canonicalUrl:http://image.slidesharecdn.com/introglusterfswebinar9302011slidesfinal-110930122614-phpapp01/95/slide-28-728.jpg
2013/07/03 10:56:45.071 kid1| store_key_md5.cc(150)
storeKeyPublicByRequestMethod: updating public key by vary headers:
accept-encoding="gzip,%20deflate" for:
http://image.slidesharecdn.com/introglusterfswebinar9302011slidesfinal-110930122614-phpapp01/95/slide-28-728.jpg
2013/07/03 10:56:45.071 kid1| store.cc(502) hashInsert:
StoreEntry::hashInsert: Inserting Entry 0x7f317e3e0410 key
'23B82F82AA4091F88B08F16AAD124879'
2013/07/03 10:56:45.071 kid1| ctx: exit level 0
2013/07/03 10:56:45.071 kid1| store.cc(901) write: storeWrite: writing
17 bytes for '23B82F82AA4091F88B08F16AAD124879'
2013/07/03 10:56:45.071 kid1| store.cc(901) write: storeWrite: writing
10 bytes for '23B82F82AA4091F88B08F16AAD124879'
2013/07/03 10:56:45.071 kid1| store.cc(901) write: storeWrite: writing 2
bytes for '23B82F82AA4091F88B08F16AAD124879'
2013/07/03 10:56:45.071 kid1| store.cc(901) write: storeWrite: writing
64 bytes for '23B82F82AA4091F88B08F16AAD124879'
2013/07/03 10:56:45.071 kid1| store.cc(901) write: storeWrite: writing 2
bytes for '23B82F82AA4091F88B08F16AAD124879'

Which indicates that the public key is being updated by vary headers
which looks a bit odd..
what is this??
accept-encoding="gzip,%20deflate"

Thanks,
Eliezer

On 07/03/2013 10:21 AM, Eliezer Croitoru wrote:
> I am working on a nice CDN thingy and it seems like squid dosn't like to
> cache a specific file which I am unsure what the source of the situation.
>
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg
>
>
> The above picture should be valid for a very long time.
> but still it wont be "cached" by squid.
> it shows a tcp_miss but with 304 in some cases.
>
> let see the headers:
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg
>
> HTTP/1.1 200 OK
> x-amz-id-2:
> JtJw8v5lPSefAEEDVApzLOWPF/Lmy7ttRT/HgRdKuLl5JAX9Rbb1pygmP8pQeuEv
> x-amz-request-id: 9FA9F1E86159EA13
> Last-Modified: Tue, 22 May 2012 21:39:05 GMT
> x-amz-version-id: G2WGsAhVccve.RJClMGhTihNIt1KLDFw
> ETag: "3393a72a72e345fc4e4a376cccc19b8a"
> Accept-Ranges: bytes
> Content-Type: image/jpeg
> Server: AmazonS3
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 41835
> Cache-Control: max-age=31536000
> Date: Wed, 03 Jul 2013 07:11:19 GMT
> Connection: keep-alive
>
> Which should be cachable for at-least very very long time on all caches.
> the local browser indeed caches this response but squid that I am using
> is not caching.
> I am trying to debug it and findout if the reason is ETAG, VARY or any
> other logical reason.
> in storelog I get:
> 1372835768.497 RELEASE -1 FFFFFFFF 3CD80312CC879BF0B4A6BC9C4961EC58 200
> 1372835768 -1 1372935768 x-squid-internal/vary -1/0 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg?1319823416
>
> 1372835768.498 RELEASE 00 00052434 1CB505B7CCAB884A87D43FDE53B6CD28 200
> 1372835445 1337722745 1404371445 image/jpeg 41835/41835 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg?1319823416
>
> 1372835768.537 SWAPOUT 00 0005243D 14024A1A79441DDDD53A39CD5A2A954B 200
> 1372835787 1337722745 1404371787 image/jpeg 41835/41835 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg?1319823416
>
> 1372835768.991 RELEASE 00 0005243C 4A81AD074E34431EAFBB0029E93C0EDF 200
> 1372835698 1372835698 1372835758 application/javascript 205/205 GET
> http://syndication.twimg.com/widgets/timelines/paged/345198371184709633?domain=www.linuxuser.co.uk&lang=en&since_id=352154234759823361&callback=twttr.tfw.callbacks.tlPoll_345198371184709633_1_352154234759823361&suppress_response_codes=true
>
>
> Which I am unsure on how to read now.
>
> in squid access.log I see that:
> 1372835884.106 127 192.168.10.124 TCP_MISS/200 42410 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg
> - HIER_DIRECT/88.221.156.163 image/jpeg
> 1372835893.774 72 192.168.10.124 TCP_MISS/200 42410 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg
> - HIER_DIRECT/88.221.156.163 image/jpeg
>
> there is no revalidation which is preferred and should be done in a case
> of reload using refresh_patttern
>
> I also tried another thing:
> 1372835980.822 155 192.168.10.124 TCP_MISS/200 42410 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg?1319823415
> - HIER_DIRECT/88.221.156.163 image/jpeg
> 1372835983.651 74 192.168.10.124 TCP_MISS/200 42410 GET
> http://image.slidesharecdn.com/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-1-728.jpg?1319823415
> - HIER_DIRECT/88.221.156.163 image/jpeg
>
> Which uses StoreID and it seems like the internals of StoreID do the
> trick for most sites but in this case there is another issue which I am
> unable to identify myself yet.
>
>
> Any points to findout what is going on and why squid wouldn't cache a
> response that firefox explorer and chrome would do???
>
> Thanks,
> Eliezer
Received on Wed Jul 03 2013 - 08:00:32 MDT