Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MimeMessageHelper does not set filename on inline MimeBodyPart #33230

Closed
rasenfer opened this issue Jul 18, 2024 · 3 comments
Closed

MimeMessageHelper does not set filename on inline MimeBodyPart #33230

rasenfer opened this issue Jul 18, 2024 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@rasenfer
Copy link

When we use MimeMessageHelper to add inline images those appears as "noname" attachment in gmail client, but are inlined correctly.
inline-with-noname

Even if we define.

			var originalFileName = Objects.requireNonNull(image.getOriginalFilename());
			var contentType = FileTypeMap.getDefaultFileTypeMap().getContentType(originalFileName);
			var byteArrayDataSource = new ByteArrayDataSource(image.getInputStream(), contentType);
			byteArrayDataSource.setName(originalFileName);
			mimeMessageHelper.addInline(originalFileName, byteArrayDataSource);

But it not is an elegant presentation for us.

To solve this we override MimeMessageHelper to add fileName on
"public void addInline(String contentId, DataSource dataSource) throws MessagingException"

public class InlineFileNameMimeMessageHelper extends MimeMessageHelper {

public InlineFileNameMimeMessageHelper(MimeMessage mimeMessage, boolean multipart) throws MessagingException {
	super(mimeMessage, multipart);
}

public void addInline(String contentId, DataSource dataSource) throws MessagingException {
	Assert.notNull(contentId, "Content ID must not be null");
	Assert.notNull(dataSource, "DataSource must not be null");
	var mimeBodyPart = new MimeBodyPart();
	mimeBodyPart.setDisposition(Part.INLINE);
	mimeBodyPart.setContentID("<" + contentId + ">");
	mimeBodyPart.setDataHandler(new DataHandler(dataSource));
	// MimeMessageHelper do not adds filename
	mimeBodyPart.setFileName(dataSource.getName());
	getMimeMultipart().addBodyPart(mimeBodyPart);
}

}

And with this change we have te expected name on preview.

inline-with-name

It is possible to add this or similiar behaviour on future releases?

Thank you.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jul 18, 2024
@snicoll snicoll changed the title inline image noname on google with: MimeMessageHelper MimeMessageHelper does not set filename on inline MimeBodyPart Jul 18, 2024
@snicoll
Copy link
Member

snicoll commented Jul 18, 2024

Thanks for the suggestion. On surface it looks sensible but I wonder if that wouldn't have unwanted side effects. We don't use the DataSource#name anywhere at the moment.

@jhoeller what do you think?

@snicoll snicoll added in: core Issues in core modules (aop, beans, core, context, expression) status: waiting-for-internal-feedback An issue that needs input from a member or another Spring Team labels Jul 18, 2024
@simonbasle
Copy link
Contributor

FYI I had a look at the various DataSource#getName Jakarta implementations and they seem to either return an empty String or a significant name (e.g. for FileDataSource, the File#getName()).

The only one I'm wondering about is URLDataSource#getName(), which returns the path (and query) of the URL. So:

dataSource = new URLDataSource(new URL("https://example.org/other/path?with-query=true"));

Would have a name of /other/path?with-query=true 🤔

That said, I would still advocate for an internal discussion on this: do we want the behavior to change or would we rather add a new overload of MimeMessageHelper#addInline?

@simonbasle simonbasle self-assigned this Jul 30, 2024
@simonbasle simonbasle added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on status: waiting-for-internal-feedback An issue that needs input from a member or another Spring Team labels Jul 30, 2024
@simonbasle simonbasle added this to the 6.2.0-M7 milestone Jul 30, 2024
@simonbasle
Copy link
Contributor

simonbasle commented Jul 31, 2024

we'll go in the additional overload direction, and add a few overloads of the addInline methods with an additional inlineFilename parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants