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

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Thu, 04 Jul 2013 01:13:31 +0300

Amos this is one of the weirdest things I have ever seen!!
the more in depth logs shows a 304 request and response while the access
log shows 200.
So I noticed that there is a Pragma header present like this:
##start
2013/07/04 01:10:16.067 kid1| http.cc(2199) sendRequest: HTTP Server
REQUEST:
---------
GET
/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-21-728.jpg?1319823419
HTTP/1.1
Host: image.slidesharecdn.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101
Firefox/22.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
Pragma: no-cache
Cache-Control: no-cache
Connection: keep-alive

----------
2013/07/04 01:10:16.102 kid1| ctx: enter level 0:
'http://slidesharecdn.squid.internal/rhintrotoglusterfsoct11final-111028123627-phpapp01/95/slide-21-728.jpg'
2013/07/04 01:10:16.102 kid1| http.cc(749) processReplyHeader: HTTP
Server local=192.168.10.1:43176 remote=88.221.156.163:80 FD 13 flags=1
2013/07/04 01:10:16.102 kid1| http.cc(750) processReplyHeader: HTTP
Server REPLY:
---------
HTTP/1.1 200 OK
x-amz-id-2: boib9MhPcFDoBTAhOtCPIhnJMcp663cUNfLv6JWFcrwRnFdYATNFjpF74A35ZYrq
x-amz-request-id: A2AB3473F4965692
Last-Modified: Tue, 22 May 2012 21:39:08 GMT
x-amz-version-id: c1_r1OArnftwzoomQNKDfuXd75JYVaEn
ETag: "b93088a8bb9fdaa382f0755077343b21"
Accept-Ranges: bytes
Content-Type: image/jpeg
Server: AmazonS3
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 98354
Cache-Control: max-age=31536000
Date: Wed, 03 Jul 2013 22:10:36 GMT
Connection: keep-alive

�
##END

So actually what can cause this kind of a problem??
the 304 is what I would have expected but I see that Pragma effect some
requests.
Can we disable Pragma Headers without modifying the request using ICAP?

Eliezer

On 07/03/2013 03:56 PM, Amos Jeffries wrote:
> On 3/07/2013 7:21 p.m., 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.
>
> Should be cacheable for up to 365 days (3153600 seconds) from its
> creation/last-modified timestamp ... which is set to a time more than
> 365 days ago now.
>
> The 304 is expected, but should be incrementing max-age value to permit
> further caching given todays date.
>
> Amos
Received on Wed Jul 03 2013 - 22:13:52 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 04 2013 - 12:00:06 MDT