Currently we have possibility to cache messages in browser. However this feature is problematic. See http://trac.roundcube.net/ticket/1486281. There're also other issues related to javascript commands included into (cached) page. Because of that we're using such complicated procedure for ETag generation:
$etag = md5($MESSAGE->uid.$mbox_name.session_id() .intval($MESSAGE->headers->mdn_sent) .intval($MESSAGE->is_safe) .(!empty($MESSAGE->attachments) ? intval($CONFIG['inline_images']) : '') .intval($PRINT_MODE) .$_SESSION['sort_col'].$_SESSION['sort_order'] .$IMAP->messagecount($mbox_name, 'ALL', true) );
It relies on messagescount, sorting, session_id, etc. It means, I think, cache is used rarely. Maybe we shouldn't allow caching messages at all?
On Tue, 24 Nov 2009 08:22:34 +0100, "A.L.E.C" alec@alec.pl wrote:
It relies on messagescount, sorting, session_id, etc. It means, I think,
cache is used rarely. Maybe we shouldn't allow caching messages at all?
I agree. You should remove message caching at all. I have problems with that feature. My whitelist plugin displays messages only if sender is in a whitelist or an addressbook. Otherwise it shows a dummy message with a button to add sender to whitelist. Currently I have to prevent caching of the dummy message by a hack in CORE which prevented me to publish my plugin.
Regards, R.
List info: http://lists.roundcube.net/dev/
2009/11/24 A.L.E.C alec@alec.pl:
Currently we have possibility to cache messages in browser. However this feature is problematic. See http://trac.roundcube.net/ticket/1486281. There're also other issues related to javascript commands included into (cached) page. Because of that we're using such complicated procedure for ETag generation:
$etag = md5($MESSAGE->uid.$mbox_name.session_id() .intval($MESSAGE->headers->mdn_sent) .intval($MESSAGE->is_safe) .(!empty($MESSAGE->attachments) ? intval($CONFIG['inline_images']) : '') .intval($PRINT_MODE) .$_SESSION['sort_col'].$_SESSION['sort_order'] .$IMAP->messagecount($mbox_name, 'ALL', true) );
It relies on messagescount, sorting, session_id, etc. It means, I think, cache is used rarely. Maybe we shouldn't allow caching messages at all?
The browser caching was initially added after Roundcube got the preview pane. For people who navigate the mesage list with the keyboard it happens that the same message (preview) is loaded several times with same settings for sorting, messagecount etc. and this is where the browser caching should kick in.
Maybe we can solve the security issue by adding some more headers but finally I don't have a strong opinion on keeping this browser caching feature alive. If more people agree to remove it, feel free to do so.
Regards, Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Roland Liebl -
Thomas Bruederli