Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
On 12-05-24 3:06 PM, Peter Peltonen wrote: Hi, On Thu, May 24, 2012 at 9:34 PM, Jean Raby wrote: We could finally reproduce the issue and it should now be fixed in the nightly builds (sope). Will there be 1.3.15b or should one install 1.3.15a + updated sope packages from nightly? And which of the sope packages should be updated: sope49-appserver The fix is in sope49-appserver, nothing changed in sogo regarding this issue. And is the nightly version 20120524 or 20120525 where this is fixed? It will be in 20120525 (tomorrow). The default apache configuration has been updated to allow the caching: AllowOverride None Order deny,allow Allow from all # Explicitly allow caching of static content to avoid browser specific behavior. # A resource's URL MUST change in order to have the client load the new version. ExpiresActive On ExpiresDefault "access plus 1 year" And when updating should one add these changes to the Apache configs manually? Since this is a configuration file, yes, it should be changed manually. Regards, Peter -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
Hi, On Thu, May 24, 2012 at 9:34 PM, Jean Raby wrote: > We could finally reproduce the issue and it should now be fixed in the > nightly builds (sope). Will there be 1.3.15b or should one install 1.3.15a + updated sope packages from nightly? And which of the sope packages should be updated: sope49-appserver sope49-sbjson sope49-xml sope49-cards sope49-gdl1-contentstore sope49-gdl1-postgresql sope49-gdl1 sope49-ldap sope49-gdl1-mysql sope49-core sope49-mime And is the nightly version 20120524 or 20120525 where this is fixed? > The default apache configuration has been updated to allow the caching: > > > AllowOverride None > Order deny,allow > Allow from all > > # Explicitly allow caching of static content to avoid browser specific > behavior. > # A resource's URL MUST change in order to have the client load the new > version. > > ExpiresActive On > ExpiresDefault "access plus 1 year" > > And when updating should one add these changes to the Apache configs manually? Regards, Peter -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
On 12-05-19 5:27 AM, Romain LE DISEZ wrote: Hi all, Le Vendredi 18 Mai 2012 18:40 CEST, Jean Raby a écrit: However, if SOGo is _not_ restarted after the upgrade, the client will see a mostly empty page. sogod should be automatically restarted after an upgrade. That's how packages work in RHEL (eg: httpd, postgresql) and Debian. A small patch is attached for RHEL. It is not tested, but it should work. Thanks for the patch. The daemon should now be restarted after an upgrade on rpm and deb platforms. -- Romain LE DISEZ -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
On 12-05-19 4:48 AM, Jean-Michel OLTRA wrote: Bonjour, Le vendredi 18 mai 2012, Jean Raby a écrit... After clearing the browser cache, all went well. I had a look to the mtime timestamp of the files: it was the one of the upgrade. I've been trying to reproduce this issue for a while, but it simply doesn't happen on my setup... At least, this sequence doesn't reproduce the problem: 1. Install 1.3.14 2. Login, check mail, logout 3. Install 1.3.15. 4. *Restart SOGo* 5. Login, check mail, logout However, if SOGo is _not_ restarted after the upgrade, the client will see a mostly empty page. This is due to the fact that we moved from scriptaculous.js to jquery.js between 1.3.14 and 1.3.15. The running SOGo would send references to the non existing scriptaculous.js and the client would get a 404. Clearing the cache and doing anything on the client side can't fix this, sogo has to be restarted. Could this be the source of the problems you were facing? Yes clearing the client cache fix it. I am sure of it, because I asked the user to clear the cache, live during a jabber session!, and the mails appeared just after (the user was complaining all day long about its lost mails). And I am mostly sure that I have restarted SOGo after its upgrade. I _always_ restart SOGo after an upgrade. I double check my bash_history, and can see the `/etc/init.d/sogo restart` after the `aptitude safe-upgrade`, so I am now 100% sure of having restarted the SOGo service! We could finally reproduce the issue and it should now be fixed in the nightly builds (sope). The problem was that apache wasn't returning any 'Expires' header in its responses for static content. This lead to browser specific behavior, where chrome and firefox would cache the content for a certain time. The time is derived from the last-modified header and could be pretty long if sogo had not been updated for a while. When a resource is cached like this, the browser does not even send a GET request for it, it simply pulls it out of its cache. (which is fast) However, clients would end up showing stale content (js, css, images, etc...) To work around this issue, the filename of a resource will now change each time the underlying file is modified. Basically, the resources now have their mtime appended to their name, for example : /SOGo.woa/WebServerResources/jquery.js?lm=1337817165 Now that we have this fix, we can tell the browser to cache the resources for a long time. The default apache configuration has been updated to allow the caching: AllowOverride None Order deny,allow Allow from all # Explicitly allow caching of static content to avoid browser specific behavior. # A resource's URL MUST change in order to have the client load the new version. ExpiresActive On ExpiresDefault "access plus 1 year" Hopefully this will be the end of this annoying behavior. -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
Romain LE DISEZ wrote: Hi all, Le Vendredi 18 Mai 2012 18:40 CEST, Jean Raby a écrit: However, if SOGo is _not_ restarted after the upgrade, the client will see a mostly empty page. sogod should be automatically restarted after an upgrade. That's how packages work in RHEL (eg: httpd, postgresql) and Debian. About that... Both times that I did the upgrade, first to 1.3.15 and then to 1.3.15a on debian 6 64-bit, it reported that it restarted the service during the installation but it didn't actually kill the old sogod process... I know this because I always tell daemons to restart after an upgrade whether apt-get says that they restarted or not (I don't trust it and for good reason). Directly after telling sogod to restart after the upgrade it tells me that it's not running and that it is starting sogod. Then I do a /etc/init.d/sogod stop and a ps -A | grep sogod and I see that there is still a sogod process hanging around. I have to do a killall -9 sogod to get rid of the stale process and then I can start and restart sogod without issue. -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
Hi all, Le Vendredi 18 Mai 2012 18:40 CEST, Jean Raby a écrit: > However, if SOGo is _not_ restarted after the upgrade, the client will > see a mostly empty page. sogod should be automatically restarted after an upgrade. That's how packages work in RHEL (eg: httpd, postgresql) and Debian. A small patch is attached for RHEL. It is not tested, but it should work. -- Romain LE DISEZ -- users@sogo.nu https://inverse.ca/sogo/lists patch-sogo_restart_after_upgrade.diff Description: Binary data
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
Bonjour, Le vendredi 18 mai 2012, Jean Raby a écrit... > >After clearing the browser cache, all went well. I had a look to the > >mtime timestamp of the files: it was the one of the upgrade. > I've been trying to reproduce this issue for a while, but it simply > doesn't happen on my setup... > At least, this sequence doesn't reproduce the problem: > 1. Install 1.3.14 > 2. Login, check mail, logout > 3. Install 1.3.15. > 4. *Restart SOGo* > 5. Login, check mail, logout > However, if SOGo is _not_ restarted after the upgrade, the client > will see a mostly empty page. > This is due to the fact that we moved from scriptaculous.js to > jquery.js between 1.3.14 and 1.3.15. > The running SOGo would send references to the non existing > scriptaculous.js and the client would get a 404. > Clearing the cache and doing anything on the client side can't fix > this, sogo has to be restarted. > Could this be the source of the problems you were facing? Yes clearing the client cache fix it. I am sure of it, because I asked the user to clear the cache, live during a jabber session!, and the mails appeared just after (the user was complaining all day long about its lost mails). And I am mostly sure that I have restarted SOGo after its upgrade. I _always_ restart SOGo after an upgrade. I double check my bash_history, and can see the `/etc/init.d/sogo restart` after the `aptitude safe-upgrade`, so I am now 100% sure of having restarted the SOGo service! -- jm -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
On 12-05-17 1:50 AM, Jean-Michel OLTRA wrote: Bonjour, Le mercredi 16 mai 2012, Jean Raby a écrit... Also, if you can reproduce the problem, can you post the apache logs where apache returns 304 (Not Modified) responses? (which cause the client to use its cached version) Here is one of our customers who was not able to view mails after the upgrade. Hope this helps! xx.xx.xx.xx - - [16/May/2012:14:06:54 +0200] "GET /SOGo.woa/WebServerResources/jquery-ui.js HTTP/1.1" 304 229 "https://www.imereos.fr/SOGo/so/xxx...@x.fr/Mail/view"; "Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4 Iceweasel/10.0.4" After clearing the browser cache, all went well. I had a look to the mtime timestamp of the files: it was the one of the upgrade. I've been trying to reproduce this issue for a while, but it simply doesn't happen on my setup... At least, this sequence doesn't reproduce the problem: 1. Install 1.3.14 2. Login, check mail, logout 3. Install 1.3.15. 4. *Restart SOGo* 5. Login, check mail, logout However, if SOGo is _not_ restarted after the upgrade, the client will see a mostly empty page. This is due to the fact that we moved from scriptaculous.js to jquery.js between 1.3.14 and 1.3.15. The running SOGo would send references to the non existing scriptaculous.js and the client would get a 404. Clearing the cache and doing anything on the client side can't fix this, sogo has to be restarted. Could this be the source of the problems you were facing? -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
Bonjour, Le mercredi 16 mai 2012, Jean Raby a écrit... > Also, if you can reproduce the problem, can you post the apache logs > where apache returns 304 (Not Modified) responses? (which cause the > client to use its cached version) Here is one of our customers who was not able to view mails after the upgrade. Hope this helps! xx.xx.xx.xx - - [16/May/2012:14:06:54 +0200] "GET /SOGo.woa/WebServerResources/jquery-ui.js HTTP/1.1" 304 229 "https://www.imereos.fr/SOGo/so/xxx...@x.fr/Mail/view"; "Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4 Iceweasel/10.0.4" After clearing the browser cache, all went well. I had a look to the mtime timestamp of the files: it was the one of the upgrade. -- jm -- users@sogo.nu https://inverse.ca/sogo/lists
Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
On 12-05-16 1:23 PM, Jeroen Dekkers wrote: At Wed, 16 May 2012 01:32:51 -0500, Aaron C Johnson wrote: On 05/16/2012 01:29 AM, Relu Parfene wrote: I updated to sogo 1.3.15 and all sope modules. I restarted sogo and memcached. After these operations in the web interface all mails are gone (including IMAP folders). I restarted the browser, I re-entered the web interface. The situation was the same. I did refresh the page (F5) and everything returned to normal. Awesome. I also noticed that the annoying card icon following the mouse disappeared in contacts page (after click on a contact in the shared address book). Absolutely awesome. I had the same problem with all the emails disappearing in the web interface. I just rebooted the server and cleared the browser cache and all was well :) I've seen those problems before with upgrades and in my opinion asking all users to clear their browser cache after every upgrade should be avoided. Indeed... As far as I understand the problem, the SOGo web resources are cached by the browser and when a new version is installed the browser has no way of knowing it has to load the web resources again. One way to fix this is to put the version somewhere in the path, so that on upgrade the web resources have a different path and the browser will fetch the new files. We implemented a workaround for this in the post install script so that the web resources' mtime are updated. Can you look at the files under /usr/lib/GNUstep/SOGo/WebServerResources and confirm that the timestamps match the installation time? Also, if you can reproduce the problem, can you post the apache logs where apache returns 304 (Not Modified) responses? (which cause the client to use its cached version) Thanks. -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
At Wed, 16 May 2012 01:32:51 -0500, Aaron C Johnson wrote: > On 05/16/2012 01:29 AM, Relu Parfene wrote: > > I updated to sogo 1.3.15 and all sope modules. I restarted sogo and > > memcached. After these operations in the web interface all mails are > > gone (including IMAP folders). I restarted the browser, I re-entered the > > web interface. The situation was the same. I did refresh the page (F5) > > and everything returned to normal. Awesome. I also noticed that the > > annoying card icon following the mouse disappeared in contacts page > > (after click on a contact in the shared address book). Absolutely awesome. > > I had the same problem with all the emails disappearing in the web > interface. I just rebooted the server and cleared the browser cache and > all was well :) I've seen those problems before with upgrades and in my opinion asking all users to clear their browser cache after every upgrade should be avoided. As far as I understand the problem, the SOGo web resources are cached by the browser and when a new version is installed the browser has no way of knowing it has to load the web resources again. One way to fix this is to put the version somewhere in the path, so that on upgrade the web resources have a different path and the browser will fetch the new files. Is there anyone who has already looked more into this issue? Is there already an open bug about this that I missed? Kind regards, Jeroen Dekkers -- users@sogo.nu https://inverse.ca/sogo/lists