From: "Will Scheidegger" Received: from asmtpout021.mac.com ([17.148.16.96] verified) by mail.obinary.com (CommuniGate Pro SMTP 5.1.10) with ESMTP id 14529795 for user-list@magnolia.info; Thu, 17 Jul 2008 10:51:26 +0200 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.42] ([85.5.249.60]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPA id <0K4500GAP78L4OP1@asmtp021.mac.com> for user-list@magnolia.info; Thu, 17 Jul 2008 01:51:18 -0700 (PDT) Sender: willscheidegger@mac.com Message-id: <1A4D702D-30D6-48B2-A21A-05E2D8299D5D@mac.com> To: user-list@magnolia.info In-reply-to: Subject: Re: [magnolia-user] Mag 3.6m3 "loosing" admin CSS after a while Date: Thu, 17 Jul 2008 10:50:45 +0200 References: X-Mailer: Apple Mail (2.928.1) Thanks for the help! Lot's of info, lots of stuff to try... will On 17.07.2008, at 10:36, Jan Haderka wrote: > On Thu, 2008-07-17 at 08:38 +0200, Will Scheidegger wrote: >> On 17.07.2008, at 08:22, Jan Haderka wrote: >> >>> Iteresting ... so your browser has the css file in its cache >> >> Well, apparently it does not... or it only has a blank page? > > If the browser didn't have it in the cache, it should not send > "If-modified-since" header. The spec says on this account: > > 14.25 If-Modified-Since > The If-Modified-Since request-header field is used with a method to > make > it conditional: if the requested variant has not been modified since > the > time specified in this field, an entity will not be returned from the > server; instead, a 304 (not modified) response will be returned > without > any message-body. > > And this is exactly what magnolia does. So if you have deleted browser > cache and browser still sends "if-modified-since" it gets empty body > from magnolia and can't render anything. > >> Browser cache, i.e. all "private data". Since Mag 3.6 I don't know >> how >> to clear the Magnolia cache anymore. And: I'm on the author instance >> so there should not be a cache in the first place be default, right? > > We try to set headers properly even on the author instance now. What > you > can try to do is to change configuration browserCache executor (class > responsible for setting those headers) and see if the problem > disappears. To do so go to > the /modules/cache/config/configurations/default/browserCachePolicy > and > change class > from info.magnolia.module.cache.browsercachepolicy.FixedDuration to > info.magnolia.module.cache.browsercachepolicy.Never > > If that doesn't help you can try to remove cache filter altogether and > see what happens. > >> >>> BTW in 3.6 there is certain amount of cached items kept in memory if >>> they are served often or recently so deleting the cache directory is >>> not enough to flush the whole cache. >> >> Interesting. > > We use EH-cache now and you can configure various setting for it > under /modules/cache/config/cacheFactory/defaultCacheConfiguration > > Cheers, > Jan > >> >>> I haven't had such problem with FF3 on linux working with various >>> snapshots/milestones/RC whole day long. >> >> Hm... as I said: we are seeing this with Magnolia running on Mac OS X >> 10.5, 10.4 and Solaris 10 accessing it from Mac OS X 10.5, 10.4 and >> Windows XP with Safari, Firefox and IE. >> >> will >> >> ---------------------------------------------------------------- >> for list details see >> http://documentation.magnolia.info/ >> ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > for list details see > http://documentation.magnolia.info/ > ----------------------------------------------------------------