[imp] problems with some types of multipart attachments

[Michael M Slusarz]

Quoting Ben Poliakoff <benp at reed.edu>:

> * 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...

This should be fixed now (the problem was that, in the popup window case, the
session was being set as readonly so the mimecache was not being updated).

michael

_______________________________________
Michael Slusarz [slusarz at curecanti.org]