But the answer is soooo simple. It just took a walk in the beautiful
California sunshine.
Combine an autoincrement Etag in the database with a modification to
the URI. So the thumbnail is now referenced as:
<img src="download.taf?_uid1=<@COLUMN "thumb_id">&ETag=<@COLUMN
"ETag">
Now the browser/proxy can cache the resource forever. But when a user
changes it, it will always cause a fresh download.
On Thursday, August 4, 2005, at 03:51 PM, Bill Conlon wrote:
Arggh. I was afraid of that. And I specifically wanted to avoid
building my own cache manager - just something else to confuse me.
I did try setting:
Cache-Control: max-age=3600, must-revalidate
Etag: "0"
I was hoping the must-revalidate would work if I incremented the Etag
on each update, but my browser doesn't pay attention. That's not to
say that some proxy server would not, but there aren't any proxy
servers in the HTTP path to my users.
I think I'll leave the ETag in place, in case browsers eventually
start using it.
Thanks very much for your thoughts.
Bill
On Thursday, August 4, 2005, at 02:53 PM, Scott Cadillac wrote:
Sorry, I ment to add:
With the "expire always" option, you can programmatically response
with "304
Not Modified" if your content hasn't changed. This way you don't have
to
waste bandwidth with resending your content everytime. It's just HTTP
traffic.
Hope that helps.
-----Original Message-----
From: Scott Cadillac [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 04, 2005 3:48 PM
To: [email protected]
Subject: RE: Witango-Talk: HTTP file cache
Hi Bill,
The eTag spec is confusing, but generally it's an extra layer
of passive
management provided by the webserver to help with cache
control when none is
explicitly provided by an application of other means.
Not only will the User's browser make cache decisions for
you, but so will
your webserver, if eTag is enabled.
The only way around all this is to purposely "not" cache your
content (via
local$HttpHeader). This way you always force the browser to check the
server.
You have to choose a strategy:
~ expire always,
~ a timed expiry
~ or give away control to the browser.
Good luck.
~ Scott Cadillac
~ 403-254-5002
~ [EMAIL PROTECTED]
~ Custom Software for Business
http://custom.softwarefor.net
~ The XML-Extranet Partnership
~ P.O. Box 69006
RPO Bridlewood SW
Calgary, Alberta
Canada T2Y 4T9
-----Original Message-----
From: Bill Conlon [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 04, 2005 3:37 PM
To: [email protected]
Subject: Re: Witango-Talk: HTTP file cache
Hi Scott,
Right, the download.taf generates the complete HTTP response
-- header plus data.
The problem is that the browser (or proxy) has cached the request,
following its own guidelines (or mine if I added the Expires
property).
When a user changes the resource on the origin server,
the browser
cache doesn't know that the cached entity no long matches
the server.
The application in question has both content-management and
content-delivery aspects. Caching is important for the
delivery, but
fresh content is needed for the management interface. One
wants long
expiry, the other short.
You may be right that "selectively expiring" content is a good
compromise. I'm curious about ETags, but I'm not sure I really
understand them from reading the RFC.
bill
On Thursday, August 4, 2005, at 02:13 PM, Scott Cadillac wrote:
Hi Bill,
Using the local$HttpHeader variable you can dictate any
HTTP response
command you like.
Generally when it comes to controlling client-side
caching I just
manipulate
the "Expires" property or sometimes set a custom cookie to
manage the
"Last
Modified" logic.
I've looked at the eTag thing, but find it overly complex for
something that
can usually be managed easier by selectively expiring your
content in
timed
intervals.
If that's not helping, I guess I don't understand what
you're after.
Remember, when it comes to client-side caching - the User's
browser
will
sometimes make decisions beyond your control.
Good luck.
~ Scott Cadillac
~ 403-254-5002
~ [EMAIL PROTECTED]
~ Custom Software for Business
http://custom.softwarefor.net
~ The XML-Extranet Partnership
~ P.O. Box 69006
RPO Bridlewood SW
Calgary, Alberta
Canada T2Y 4T9
-----Original Message-----
From: Bill Conlon [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 04, 2005 2:56 PM
To: [email protected]
Subject: Re: Witango-Talk: HTTP file cache
What about entity tags
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3)?
I would have an auto increment column associated with the
thumbnail (or
the source document for that matter) to use an E-Tag instead of
last-modified in the response header of download.taf.
I presume if you provide an entity tag, the User-Agent
will have to
re-validate every file, but in most cases would use the cached
resource. Anyone have any experience with this?
On Thursday, August 4, 2005, at 01:45 PM, Bill Conlon wrote:
Thx Scott & Roland. Using &<@RANDOM> will indeed cause the
freshly updated image to be displayed for the admin user
that updated
the content.
But I really want the cached items refreshed, so that other
users will
get the new thumbnail. I hate the idea of losing the
ability to cache,
but I need to think about this.
bill
On Thursday, August 4, 2005, at 01:26 PM, Scott Cadillac wrote:
Hi Bill,
Have you tried:
<img src="download.taf?_uid1=<@COLUMN
"thumb_id">&random=<@RANDOM>">
Just have your server-side code ignore the "random" argument.
Works for me.
~ Scott Cadillac
~ 403-254-5002
~ [EMAIL PROTECTED]
~ Custom Software for Business
http://custom.softwarefor.net
~ The XML-Extranet Partnership
~ P.O. Box 69006
RPO Bridlewood SW
Calgary, Alberta
Canada T2Y 4T9
-----Original Message-----
From: Bill Conlon [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 04, 2005 2:21 PM
To: Witango-Talk
Subject: Witango-Talk: HTTP file cache
I know a few people on this list have addressed the issue
of dealing
with cached files. Here's my scenario:
I go to an admin page, and get some info on a file stored
in the db.
The page includes a thumbnail (also stored in the
db), such as:
<img src="download.taf?_uid1=<@COLUMN "thumb_id">
the browser requests and caches the thumbnail image.
Response header
for this download is:
http://ccmh3.tothept.com/download.taf?_uID=165
Date: Thu, 04 Aug 2005 19:13:17 GMT
Server: Apache/2.0.54 (Unix) mod_perl/1.99_16
Perl/v5.8.5 DAV/2
PHP/4.3.10
Accept-Ranges: bytes
content-disposition: inline;
filename=spiritofcaring_gray_thumb.jpg
Last-Modified: Monday, 22-Sep-2003 10:48:26 GMT
Content-Length: 5448
Content-Type: image/jpeg
I then upload a replacement file, and in the process, the
application
invokes ImageMagick to generate a new thumbnail, and then
displays the
same page with updated information. Again the thumbnail is
referenced
as
<img src="download.taf?_uid1=<@COLUMN "thumb_id">
but the previous, cached, version appears.
If I force a cache refresh, my new response header looks like:
http://ccmh3.tothept.com/download.taf?_uID=165
Date: Thu, 04 Aug 2005 19:42:50 GMT
Server: Apache/2.0.54 (Unix) mod_perl/1.99_16
Perl/v5.8.5 DAV/2
PHP/4.3.10
Accept-Ranges: bytes
content-disposition: inline;
filename=thumb_spiritofcaring_logo_gray_sm.png
Last-Modified: Thursday, 04-Aug-2005 12:42:05 GMT
Content-Length: 6681
Content-Type: image/png
The thumbnail info is generally static, and should
therefore be
cacheable, but in this case I'm displaying the stale info.
Does anyone
know any tricks, or must I instead create an entirely new
URI, giving
the thumbnail a new ID?
thanks.
Bill
______________________________________________________________
__________
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________
________
__
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________
_________
_
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________
__________
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________
_________
_
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________
__________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________
__________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_______________________________________________________________________
_
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
