Check if attachment is actually(!) referred to #9585
Conversation
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
d9fe09b
to
73cbc95
Compare
pabzm
changed the title
If there's no reference to it in a sibling HTML part then we handle it as a classic attachment (which is shown as downloadable).
Previously all headers were only fetched for message/rfc822, or if the Content-Type's "name" parameter was set, or if a Content-ID was set. The RFC doesn't require neither the "name" parameter nor a Content-ID for using Content-Location, though, so we shouldn't depend on those. Instead now all headers are also fetched if the main part of the Content-Type is "image", to catch more cases.
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
73cbc95
to
636dcdf
Compare
| } | ||
| // Note: There might be more than one HTML part, thus | ||
| // we use a callback and concatenate the results. | ||
| $html_content = implode('', array_map(function ($part) { return $this->get_part_body($part->mime_id); }, $html_parts)); |
There was a problem hiding this comment.
There's indeed my @todo comment 70 lines below to get the HTML bodies and check for references. However, this has a performance impact, that for a message with many images and big HTML content might be noticeable. As of now I considered fetching part headers acceptable, but part body is another story.
We need some more considerations. For example, when loading an image attachment (rcmail_attachment_handler) maybe we could fetch the image without needing to parse the message structure and loading HTML parts again only to get the attachment part data.
Maybe checking for references must be done outside of rcube_message. So rcube_message is not that heavy (to not slow down all the cases where we deal with the message), but do not really need the full structure information, e.g. when viewing source or downloading the message, or when dealing with a single attachment.
Or maybe we need to use cache. It might not help much when dealing with parallel requests (loading image attachments) though. And caches are usually optional.
There was a problem hiding this comment.
I see your point and am working on it.
This finishes what #9472 intended to do – but didn't actually do, as I found out.
The code now checks for each non-text mime-part in a multipart-part if its
Content-IDorContent-Locationis (probably) used in a sibling HTML-part, and only if that matches the respective mime-part is considered an "inline" attachment (that won't show up as downloadable or below the message content).The second commit in this PR makes sure that for all image-parts, all mime-part-headers are loaded from the server, in order to actually get hands on the
Content-Location-header (which isn't always fetched in the first place). It is limited to image-parts because those are the most common ones maybe having aContent-Location-header and I assumed that we shouldn't load the headers for every mime-part, so this seems like a workable real-world distinction for me.One could probably change how the
BODYSTRUCTUREresponse is fetched and parsed to ensure aContent-Location-header is always fetched in the first place, but I didn't dare to touch that code.This fix closes #9565