Check if attachment is actually(!) referred to #9585
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
d9fe09b to
73cbc95
Compare
pabzm
changed the title
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
73cbc95 to
636dcdf
Compare
alecpl
reviewed
Aug 17, 2024
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
2 times, most recently
from
1373f57 to
8f12091
Compare
Merged
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.
We want it tested!
We decide later, which attachment is considered "inline" and which isn't.
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
8f12091 to
54a692c
Compare
pabzm
force-pushed
the
check-if-attachment-is-actually-referred-to
branch
from
698570d to
321d1c6
Compare
|
I would like to integrate a lot more messages into the "Message Rendering" tests, but the rest of the code is ready as it is, and I can supplement additional tests later, too. |
|
@alecpl Could you have another look at this, please? |
alecpl
reviewed
Jan 7, 2025
| { | ||
| if ($this->check_context($part)) { | ||
| // It may happen that we add the same part to the array many times | ||
| // use part ID index to prevent from duplicates | ||
| switch ($type) { | ||
| case 'inline': | ||
| $this->inline_parts[$part->mime_id] = $part; |
There was a problem hiding this comment.
Looks like you removed a public $inline_parts property, so remove it's declaration, please.
| Content-ID: <2478d4f4b6b373ac9292cdbab380ee6bd4e4a16ee4feef5112ac3fe61b1303fe> | ||
| Content-Transfer-Encoding: base64 | ||
|
|
||
| iVBORw0KGgoAAAANSUhEUgAAAlsAAAKYCAYAAABEuT1rAAAAAXNSR0IArs4c6QAAAARnQU1BAACx |
There was a problem hiding this comment.
It would be good to keep the test data small. I.e. use some simple/small images.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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