Re: [Plone-Users] Javascript/CSS caching

[Derek B. <de...@po...>]

Ricardo Newbery wrote:

> 
> On Mar 2, 2010, at 5:45 AM, Derek Broughton wrote:
> 
>>> No.  I am saying that the changing Last-Modified header is not doing
>>> anything for you with respect to getting a 304 response.  But it's
>>> also not causing any issues with caching.
>>
>> I know that, but it's a symptom of the fact that we don't know when
>> the file
>> was modified.
> 
> 
> Sorry, what does this mean?  Caching works fine.  It's only the 304
> response that doesn't work.

I disagree.  The fact that you don't get a 304 _proves_ server-side caching 
isn't working.

> Not sure what you mean by "caching is a server function".  Caching can
> happen in the server, in a proxy, or in the browser.  

I'm not convinced that relying on a proxy is right - but it's clear I'll 
have to.  Caching on the browser side is notoriously unreliable.

> Caching in
> proxies and browsers is controlled usually via cache control headers.
> Caching in the server is much easier (although potentially resource
> hungry) and doesn't require cache control headers.
> 
> In either case, the Last-Modified header has *no* affect on caching
> behavior.  

How many times do I have to say that?  I said, from the start, that it's 
purely a symptom.  The fact that you don't know _when_ the file was modified 
makes it impossible to cache on the server side.

> Don't confuse caching with validation.  The Last-Modified
> validation header is only useful for that portion of your users that
> already have a copy of the resource in their browser cache AND that
> resource has expired.  

No, it's relevant when the client requests a new file, whether expired or 
not.

>>> Yes, it does.  Again, you're testing 304 behavior here, not cache
>>> behavior.
>>
>> Please explain the difference.  If the file is cached, it shouldn't
>> be being
>> _sent_, and the only way to do that afaik is to send a 304 to
>> instruct the
>> browser to use the old one.
> 
> 
> Cached where?
> 
> Cached in browser?  

No!  From the start, I've been asking why the _server_ doesn't handle 
caching as it should.  I explicitly pointed out that I was intentionally 
overriding any browser cache.

> Then yes.  When the browser cache expires, it's

OR is overridden

> nice to leverage 304s to cut down on the bandwidth costs of a full
> response.  The critical qualification here is "when the browser cache
> expires".  If it only expires after a year, then 304s are a pointless
> optimization -- no one will ever notice that their browser experiences
> a tiny delay to refresh its cache once a year.

That's not true.  If I hit the refresh button, on most browsers (but not 
IE), it doesn't matter whether the browser has the file in cache, it will 
request a new one.

> Cached in server?  Then no.  304s are *only* useful if its cached in
> browser.  Internally, the server should not need special request
> headers to check the freshness of its own cache if it's designed
> well.  The server cache should be purged whenever the resource
> changes, or if not purged, should be able to check the age of a cached
> entry internally.  HTTP/1.1 tricks like Last-Modified and ETag headers
> or conditional requests are not needed for the server to maintain an
> internal fresh cache.

Then why does it keep serving up the same files over and over?
-- 
derek