|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Adding email exchange on jenkins forum with Slide that preceded opening of this issue.
Slide [email protected]
6:41 PM (12 hours ago)
to Jenkins
File an issue and I'll get to it when I can.
On Mon, Apr 21, 2014 at 4:12 PM, Stephan Lips <[email protected]> wrote:
Hmmm. So I looked at the src for CssInliner. Most interesting is that if the attribute data-inline="true" is set on an <img> node, the image is retrieved, base64-encoded, and included inline. So I did a li'l test, where I referenced an image via URL, setting data-inline="true". And lo and behold, the resulting base64-encoded string that arrived in my inbox had .... the '+' characters replaced with + (prohibiting it from rendering)
Other than that, the only code that explicitly deals with the '+' for replacement is line 135:
String trimmedStylesheet = stylesheet.replaceAll("\n", "").replaceAll("/\\*.*?
*/", "").replaceAll(" +", " ");
and would not apply, due to the leading space.
So looks like this issue manifests itself with use of the data-inline attribute, making that feature essentially unusable. In general, base64-encoded strings (or '+' chars anywhere in the email content) do not work with ext-email.
So where/how do we go from here?![]()
Thx, S
On Mon, Apr 21, 2014 at 5:43 PM, Slide <[email protected]> wrote:
Hmm, actually, it looks like the CssInliner could be doing something. It processes anything that is text/html. I had forgotten about that because I didn't write that part. There is currently not a way to turn it off.
On Mon, Apr 21, 2014 at 3:24 PM, Stephan Lips <[email protected]> wrote:
Nope, does not make a difference. I blank'd out all fields in the default email configuration, and configured the ext-email plug-in overrides. '+' characters in email content still arrive as +
Is some jenkins/ext-email dependency doing this?
Thx, S
On Mon, Apr 21, 2014 at 3:59 PM, Slide <[email protected]> wrote:
Email-ext DOES have it's own server configuration, you just have to check "override default settings" in the global config. That would be another thing to try, overriding the default settings so that the session is created completely in email-ext.
On Mon, Apr 21, 2014 at 12:37 PM, Stephan Lips <[email protected]> wrote:
If I check 'save to workspace' the '+' chars are not being escaped with +.
FWIW, I also tried a couple different email providers (my corporate smtp server, and google), in both cases the arriving email had the '+' substituted for ". Since ext-email does not have its own mail server configuration, I assume it is piggy-backing of the standard email configuration/server. Is this substitution happening further downstream, e.g. in the regular email code?
Thx, S
On Mon, Apr 21, 2014 at 2:16 PM, Slide <[email protected]> wrote:
I don't know of anything in the email-ext code that would escape anything like you are describing. Can you try checking the "save to workspace" checkbox in the project settings and see if the same escaping is shown in the saved off file?
On Mon, Apr 21, 2014 at 11:08 AM, Stephan Lips <[email protected]> wrote:
Yes, the issue reproduces with a template. Curiously, when testing the template (through the 'Email Template Testing' link in the workspace), the inserted base64 string renders correctly. The received email, however, still sees the + escapes instead of the '+' char, causing the base64 img src to not render.
The template I'm using (saved to $JENKINS_HOME/email-templates) is
<TABLE>
<TR><TD align="right"><IMG SRC=""blue.gif" : build.result.toString() == 'FAILURE' ? 'red.gif' : 'yellow.gif' %>" />
</TD><TD valign="center"><B style="font-size: 200%;">BUILD ${build.result}</B></TD></TR>
<TR><TD>Build URL</TD><TD><A href="">${rooturl}${build.url}</A></TD></TR>
<TR><TD>Project:</TD><TD>${project.name}</TD></TR>
<TR><TD>Date of build:</TD><TD>${it.timestampString}</TD></TR>
<TR><TD>Build duration:</TD><TD>${build.durationString}</TD></TR>
</TABLE>
<BR/>
<img src=""my-image.b64").readToString() %>" width="700" height="400">
The file 'my-image.b64' is confirmed to exist in the workspace, and contain valid base64. The contents of the file are inserted correctly, save for the html-escaped '+' char.
So, how do I turn off html escaping of content?
Thx, S
On Mon, Apr 21, 2014 at 9:59 AM, Slide <[email protected]> wrote:
Yes, I'd like you to try and see if the issue occurs with a template.
On Apr 21, 2014 6:49 AM, "Stephan Lips" <[email protected]> wrote:
It reproduces without any templates. Simply put the following in the 'Default Content' field of the ext-email configuration:
<img src=''/>
a+b
The email received will show the above as
<img src="">
a+b
(note the " in place of the '+' signs).
Thx,
On Fri, Apr 18, 2014 at 8:37 PM, Slide <[email protected]> wrote:
Can you try using a groovy template instead of just trying to generate the HTML yourself? I'm not sure why the text is being encoded like you mention. I can try and recreate if you send the file you are using and the template.
On Apr 18, 2014 5:48 PM, "stephanl" <[email protected]> wrote:
So then, do you know if there is a way to send a base64 as-is in an email? E.g. without being html-escaped implicitly? Looks like some macro tokens support this, through the escapeHtml attribute. I did not see anything in the ext-email code base suggesting there is a global option/switch, or for individual fields. But I also did not see on cursory glance where the html escaping occurs, so is there an option somewhere else?
Thx, S
On Friday, April 18, 2014 4:08:36 PM UTC-5, slide wrote:
There is no capability to add a different content type.
On Fri, Apr 18, 2014 at 1:16 PM, stephanl <[email protected]> wrote:
HTML (text/html). For grins, I tried Plain Text (text/plain), in which case the base64 string was included un-escaped, but (of course) not recognized/rendered as image when the containing email was viewed. In the configuration section of the ext-email plugin these are the only two options (text/html and text/plain). If another content-type is required, how do I add it (UI does not show option to add addt'l content types, using latest jenkins and ext-email versions), and what should it be?
Thx, S
On Friday, April 18, 2014 3:08:05 PM UTC-5, slide wrote:
What is your content type set to in the settings?
On Fri, Apr 18, 2014 at 12:52 PM, stephanl <[email protected]> wrote:
Not using templates. Tried using
<img src='' width="900" height="550"/>
in the 'Default Content' section/field of the ext-email plugin. Also tried using
def reportPath = build.getWorkspace().child("my-base64-encoded-png.b64")
msg.setContent("<img src=''/>", "text/html");
as pre-send script (also in the ext-email plugin, Advanced section). From what I can tell, the html encoding occurs after the default content and pre-send scripts have been processed/executed. Which would apply to templates as well, no?
Thx, S
On Friday, April 18, 2014 12:31:05 PM UTC-5, slide wrote:
Are you using a groovy or jelly template, or generating the HTML yourself?
On Fri, Apr 18, 2014 at 10:20 AM, stephanl <[email protected]> wrote:
Howdy,
I am trying to embed a base64 img src in the body/content of an ext-email notification, like so:
<img src='' width="900" height="550"/>
The email I receive has all '+' characters in the included base64 string escaped as +. I tried to set the email content in a pre-send groovy script, like so:
def reportPath = build.getWorkspace().child("my-base64-encoded-png.b64")
msg.setContent("<img src=''/>", "text/html");
and still see the escapes for the '+' in the email received. I do not see an option to turn off html escaping (except for a few macro tokens, which I am not using).
Any insights/advice on how I can embed a base64 image in an email without triggeriung automatic encoding of the base64 string? And no, referencing the image by URL is not an option, unfortunately. Last, for grins I have included verbatim strings in the email body/content, like 'A+B' and "A+B", in all cases the '+' character arrived encoded.
TIA,