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 - 12:56:57 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 04 2013 - 12:00:06 MDT