[imp] problems with some types of multipart attachments

[Ben Poliakoff]

* Michael M Slusarz <slusarz at mail.curecanti.org> [041028 17:05]:
> >
> >Does anyone have any idea why the "index" and "mailbox" arguments might
> >be missing when viewing these multipart MIME messages?
> 
> Because, for embedded MIME parts, the 'index' and 'mailbox' doesn't 
> exist as the
> MIME part exists entirely independent of the underlying IMAP message data.
> 
> I've moved an overzealous empty $index check to the correct position in 
> view.php
> so this should be working again.
> 

Cool, that certainly seems to fix all of the issues with
multipart/signed MIME messages!  It also fixes some of the issues with
multipart/appledouble MIME messages, but not all.

In a nutshell when the appledouble viewer is called in a "popup_view"
context it uses the wrong "mimecache" when it generates the URL for the
data fork.  

Read on for further (and lengthy) details...

When "Content-Disposition" for a multipart/appledouble MIME message
is set to "inline" then the appledouble viewer kicks in and displays
several links in the main message view window: 

    - a link to the resource fork 
    - a link to "view" the attached file, if it's viewable according
      to mime_drivers.php
    - a link to download the file

However, when "Content-Disposition" for a multipart/appledouble
MIME message is set to "attachment" then the appledouble viewer
is only called when the user follows the link to the entire
multipart/appledouble attachment (containing the resource and
dataforks).  When the user follows that link a window pops up with
content generated by the appledouble viewer.  The problem that I'm
seeing is here.

First here's the link from the main message view window for the
"popup_view" window for a multipart/appledouble MIME message (the link
is embedded in javascript):

/horde/imp/view.php?popup_view=1&amp;index=9&amp;mailbox=INBOX.attachments&amp;actionID=view_attach&amp;id=2&amp;mimecache=ac2eb2e05e59519641b6dda0396440f8

Here are the two URLs from the above "popup_view" window.

Resource fork (this link works):

/horde/services/download/?module=imp&thismailbox=INBOX.attachments&index=9&mailbox=INBOX.attachments&actionID=download_attach&id=2.1&mimecache=ac2eb2e05e59519641b6dda0396440f8&fn=%2Funnamed

Data fork (this link doesn't work, I get a blank page):

/horde/services/download/?module=imp&actionID=download_attach&id=2.2&mimecache=96353e90b97abdc1569a88c431eafc51&fn=%2Ftest_document

But If I take the URL for the data fork and change the mimecache value
to the value from the resource fork URL then I'm able to successfully
download the data fork.

So somehow the mechanism that is generating the URL for the data fork is
getting the wrong mimecache!

This problem only jumps out at you when "Content-Disposition" for a
multipart/appledouble MIME message is set to "attachment".  But it
seems to be present in all cases as long as you are looking at the
"popup_view" window for the whole multipart/appledouble MIME message.
It's not as big an issue for "inline" appledouble attachments because
the appledouble viewer is invoked within the main message viewing
window.  But for multipart/appledouble messages with
"Content-Disposition" of "attachment" then you have to use the
"popup_view" to try to get at the attached files...

I'm seeing it on two different Horde CVS HEAD installations.  And it
happens whether imp is talking directly to our cyrus imap server or if
it's talking to the up-imapproxy server that runs on the web server.

Sorry this has gone on at such length!  But I wanted to be as specific
as possible in my description of the problem I'm seeing.

Ben

-- 
________________________________________________________________________
Ben Poliakoff <benp at reed.edu> | Unix System Administrator | Reed College
PGP fingerprint:      A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019