-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Underscores being interpreted as spaces (%20) in HTML body links. #41
Comments
Thanks @rosstimson, i'll investigate asap! |
I can also replicate this issue if it's of any help. |
Yes I can replicate it too |
thanks all, and sorry, haven't had a chance to look at this yet - hopefully will soon! (but PR's welcome if anyone does has a fix) |
Bug confirmed here too. @ian-kent any news regarding that issue? Can you drive us where to look at to try to fix it? |
Sorry its taken a while to get around to looking at this - could anyone provide some example content please? Just tried to reproduce it, but with a basic HTML e-mail it works as expected:
Wondering if it might be something to do with content encoding |
@ian-kent seems like problem in HTML renderer. I use send to mailhog your html, and in Plan Text tab all OK
But in HTML tab
|
Thanks @slonoed - can you provide the full SMTP message you used, I can't reproduce the bug with just the headers in the example I gave |
I think this is fixed now - RFC2047 encoding was replacing a "_" with a " " before decoding, which is correct when applied to headers, but not the message body. Please reopen if it hasn't been fixed 😄 |
We are using Mailhog fairly extensively at work on test instances and members of development teams have been mentioning an issue with regards to underscores in links in the HTML body being wrongly interpreted as spaces.
For example if the email body has a link
email_activation
it gets interpreted asemail%20activation
. This apparently happens for all links that use underscores as we also see this glitch with image names that contain underscores that then just 404.I hope this makes sense and if we need to investigate further I will involve some of my developer colleagues to shine some more light on this.
The text was updated successfully, but these errors were encountered: