Hi Thomas, After much interesting debugging, I've found the problem and fixed it.
Here is a patch, and a copy of the file with the patch applied. (merged with svn today) The problem I've fixed was in the imap library. I am not sure if it's the imap server I have (Communigate Pro) not implementing imap correctly, or if the library that is wrong. If the IMAP fetch specification says that the termination of a fetch command is ) at the beginning of a new line, then this is a work around for imap servers that do not follow the spec. If however, the specification for IMAP is that ) is at the end of a line that does not contain a : in it, then this patch fixes the imap library. I think this patch, being an addition of just 1 line and some comments is fairly trivial so should not risk breaking too much else. I've written the comments as I suspect maybe other people will also be affected by this problem. Regards Glen Ogilvie On Thu, 08 Nov 2007 10:54:13 pm you wrote: > Glen Ogilvie wrote: > > Hi, > > Hi Glen, > > > I've got a tricky roundcube problem. It seems related specifically to > > our communigate pro imap server. When clicking on reply, none of the > > header information that should be in a reply gets populated (subject, > > original email date, recipient). > > This was already reported once but none of the devs was able to reporduce > it. I hope we can get it fixed with your help now... > > > I've noticed that this always happens when the preview pane is turned on, > > and only sometimes happens when the preview pane is off. > > Not sure if this has something to do with the preview pane. > > > I've been using roundcube elsewhere for quite some time with a courier > > imap server, and don't have the same problems. > > We found out that it's related to a specific IMAP server and not a general > problem. > > > I've looked at compose.inc, rcube_imap.inc and imap.inc, however, I am > > struggling to find out the cause of this problem. > > compose.inc fetches the headers using $IMAP->get_headers($uid) which should > work since this is used everywhere. > > When looking at the code I found out that compose.inc also calls > $IMAP->get_structure($uid) which then again calls $IMAP->get_headers() but > with the message ID and not the UID. This explains why you see two FETCH > requests, one with UID FETCH 6095 and another with FETCH 927. > > However your IMAP server seems to accept the UID FETCH command and return > the requested headers. > > > Any ideas of what to look for would be appricated. I am a php developer, > > so happy to hunt around in the code, just struggling to get my head > > around what is supposed to happen. Running rev 912 from svn. > > > > If I set $rcmail_config['enable_caching'] = FALSE; > > Then this problem occurs all of the time. > > Hmm, this is strange... > > > I've done a tcpdump of the traffic between roundcube and the imap server. > > Something that I don't quite understand is why the appears to be 2 imap > > queries. > > > > [...] > > I've just committed (r913) some improvements to optimize the internal > caching and to prevent unnecessary requests to the IMAP server. Not sure if > this solves your problem but you should update your SVN checkout. > > To track it down you can dump some vars in rcube_imap::get_headers() and > rcube_imap::get_structure() in order to find out where those headers get > lost when replying to a message. > > Thanks so far! > ~Thomas -- Glen Ogilvie Open Systems Specialists Level 1, 162 Grafton Road http://www.oss.co.nz/ Ph: +64 9 984 3000 Mobile: +64 21 684 146 GPG Key: ACED9C17 --- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/yK/f92Ba/uR/imap.inc http://detached.gigo.com/rc/yK/f92Ba/uR/imap.patch Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
_______________________________________________ List info: http://lists.roundcube.net/dev/
