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
