Re: [squid-users] caching dynamic image content

On Thu, Aug 13, 2009 at 9:32 AM, Terry<td3201_at_gmail.com> wrote:
> On Thu, Aug 13, 2009 at 8:10 AM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>> Terry wrote:
>>>
>>> Hello,
>>>
>>> I don't have squid implemented yet.
>>>
>>> I am researching a web architecture issue I am seeing with a site.
>>> Squid may be a bandaid for what I think may be some poor development
>>> architecture decisions.  There are concerns that the site is written
>>> in a way that browsers and reverse proxies cannot cache it
>>> appropriately. And these aren't my concerns by the way.  We also have
>>> A10 load balancers in house that do some caching.  They said they
>>> can't cache this content.  I don't want to go into their reasoning
>>> because I don't believe it.
>>>
>>> Here's an example of an image as seen from the client.  I pulled this
>>> right out of my firefox memory cache:
>>> http://foo.domain.com/Image.aspx?i=db1edbcd-2375-4bae-b33f-a53ced60deed
>>>
>>> 1. If it's in the memory cache, can I assume that browsers and proxies
>>> can cache it?  Also, I never saw these objects in my disk cache.  Not
>>> sure if that's significant or not.
>>
>> No. The browser has additional information such as who is logged in and
>> whether your session with the website is the same. They are also allowed to
>> cache objects personal to you.
>>
>> Proxies and caches only have the URL and some other limited data to base the
>> checking on. If there is any chance it was a private object it will not be
>> cached naturally.
>>
>>>
>>> 2.  Does firefox still interpret this as an image and cache it as one
>>> or is this considered dynamic content that may be problematic?
>>
>> Not enough information to even guess. What headers are present? Does the
>> website require login? does the same image ever change URL (including the
>> query string) and why/when/how often? are alternative image formats
>> available at the exact same URL?
>>
>> Any one of those answers may make the object non-cacheable by shared
>> proxies.
>>
>>>
>>> I think that's enough information to start a conversation.  Thanks for
>>> any insight!
>>
>>  foo.domain.com does not resolve here so I can't verify the object.
>> Please pick some of the URLs and enter them into http://www.redbot.org for
>> review of cacheability.
>>
>> Amos
>> --
>> Please be using
>>  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18
>>  Current Beta Squid 3.1.0.13
>>
>
>
> Thank you both for replying.  I haven't messed with squid and caching
> for 5+ years and its all slightly coming back to me.  The identifier
> in the URL is not unique based upon the session of the user.
> https://foo.domain.com/Image.aspx?i=db1edbcd-2375-4bae-b33f-a53ced60deed
>
> the i=db1edbcd-2375-4bae-b33f-a53ced60deed is a unique identifier for
> the image and its size.    Based on that, it should be cacheable but
> the developers are setting it to nocache for some reason.  I am
> guessing they reused some code for other dynamic content and failed to
> see this aspect.
>

Just to further prove its not being cached, here's the header:

GET /Pic.aspx?i=db1edbcd-2375-4bae-b33f-a53ced60deed HTTP/1.1
Host: foo.domain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://foo.domain.com/
Cookie: com.domain.foo_SessionID=kua4ew454kjodsjpdlojdu55
Cache-Control: max-age=0
Received on Thu Aug 13 2009 - 14:49:28 MDT