-
Bug
-
Resolution: Fixed
-
Major
-
2.28, 915bc21
-
-
iapetus
Scope
- Force text/plain content type on full log endpoint
Original Request
When displaying the full log for a step, e.g. at https://jenkins.my-domain.com/blue/rest/organizations/jenkins/pipelines/Org/project/branches/master/runs/90/log/?start=0, the log is rendered as HTML with colors, anchors, etc., but line breaks are not renders as <br />.
That's fine to do, but if so, the body should have a `style="white-space: pre-wrap"` or you end up with an enormous wall of unbroken text.
[JENKINS-39521] Full Log does not render newlines - or use correct content type (weird HTML like artifacts)
Samuel Reed
added a comment - Sure, here's a snippet. It may be important that I am using the AnsiColor and Timestamper plugins.
Samuel Reed
added a comment - Sure, here's a snippet. It may be important that I am using the AnsiColor and Timestamper plugins.
Samuel Reed
added a comment - The same with `white-space: pre-wrap` on the body:
strml thanks. I think at some point this change stopped applying https://github.com/jenkinsci/jenkins-design-language/pull/95/files
tscherler can you confirm please?
jamesdumay I don't see any stylesheet loaded whatsoever. This is the entire head:
<head> <style type="text/css"> :root #header + #content > #left > #rlblock_left { display: none !important; } </style> </head>
Samuel Reed
added a comment - - edited jamesdumay I don't see any stylesheet loaded whatsoever. This is the entire head:
<head>
<style type= "text/css" >
:root #header + #content > #left > #rlblock_left
{ display: none !important; }
</style>
</head>
strml ahh my apologies. I believe your referring to the full log? We only serve that in plain text.
Samuel Reed
added a comment - Yep that's the one, but it actually is served as HTML (perhaps the plugins are doing it?).
Connection:keep-alive
Content-Encoding:gzip
Content-Length:20104
Content-Type:text/html;charset=UTF-8
Date:Mon, 07 Nov 2016 00:58:50 GMT
Server:nginx/1.4.6 (Ubuntu)
X-Text-Size:675129
It's basically text with anchor tags, no <html> or <body>, etc.
Samuel Reed
added a comment - Yep that's the one, but it actually is served as HTML (perhaps the plugins are doing it?).
Connection:keep-alive
Content-Encoding:gzip
Content-Length:20104
Content-Type:text/html;charset=UTF-8
Date:Mon, 07 Nov 2016 00:58:50 GMT
Server:nginx/1.4.6 (Ubuntu)
X-Text-Size:675129
It's basically text with anchor tags, no <html> or <body>, etc. strml I don't think we can serve this one up in HTML like you've asked for in this ticket. Unbounded log file rendered with some CSS will likely hang your browser.
Quick question, what is taking you back to the full log?
Samuel Reed
added a comment - It's already HTML. I'm not sure what's automatically creating the anchors, but it's not AnsiColor (verified by removing it). So that's more or less a sunk cost.
Alternatively, if it were formatted as plain text with no formatting whatsoever, it might render more quickly. It would have to be a huge build for it to matter..
The full log is the link from the pipeline. There's an example in the original description.
Samuel Reed
added a comment - It's already HTML. I'm not sure what's automatically creating the anchors, but it's not AnsiColor (verified by removing it). So that's more or less a sunk cost.
Alternatively, if it were formatted as plain text with no formatting whatsoever, it might render more quickly. It would have to be a huge build for it to matter..
The full log is the link from the pipeline. There's an example in the original description. strml being the Jenkins project we have to take into account those huge builds 
I think we certainly need to send the right content type here.
jamesdumay the full log is coming from jenkins directly bo is not directly serving this. AFAIR vivek implemented that.
strml I am told it operates purely on the Accept header. I don't think the browser is doing much work in this case and we haven't had any performance reports.
Closing this out as Not A Defect. If there is any reason to open this ticket again please do so.
Samuel Reed
added a comment - Excuse my incredulity, but you are saying that it is "Not A Defect" that logfiles as served by Jenkins/BO don't respect newline characters?
So logs looking like is just fine?
Samuel Reed
added a comment - Excuse my incredulity, but you are saying that it is "Not A Defect" that logfiles as served by Jenkins/BO don't respect newline characters?
So logs looking like is just fine? 
strml see above screenshot with the following header set.
Can you provide a the later from your system.
Samuel Reed
added a comment - tscherler I posted this a few comments up: https://issues.jenkins-ci.org/browse/JENKINS-39521?focusedCommentId=276144&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-276144
Samuel Reed
added a comment - tscherler I posted this a few comments up: https://issues.jenkins-ci.org/browse/JENKINS-39521?focusedCommentId=276144&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-276144 that are the response header, I asked you for the request header.
No, you said "please provide the later" and showed me a picture of your console.
Response Headers ---------------- Connection:keep-alive Content-Encoding:gzip Content-Length:18936 Content-Type:text/html;charset=UTF-8 Date:Tue, 08 Nov 2016 13:53:16 GMT Server:nginx/1.4.6 (Ubuntu) X-Blueocean-Refresher:GjD6b4VWeWwD----- X-Content-Type-Options:nosniff X-Text-Size:546612 Request Headers --------------- Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding:gzip, deflate, sdch, br Accept-Language:en-US,en;q=0.8,zh;q=0.6 Cache-Control:no-cache Connection:keep-alive DNT:1 Host:jenkins.mydomain.com Pragma:no-cache Referer:https://jenkins.mydomain.com/blue/organizations/jenkins/MyOrg%2Ffrontend/detail/master/272/pipeline Upgrade-Insecure-Requests:1 User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 Query String Parameters ----------------------- start:0
Just a note, this error is BO-specific, the traditional Jenkins full log (both HTML & plain text, as in <project>/job/<branch>/<jobNum>/consoleText), show up fine.
My pipeline is wrapped with the following:
timestamps {
node {
wrap([$class: 'AnsiColorBuildWrapper', 'colorMapName': 'XTerm', 'defaultFg': 1, 'defaultBg': 2]) {
Samuel Reed
added a comment - - edited No, you said "please provide the later" and showed me a picture of your console.
Response Headers
----------------
Connection:keep-alive
Content-Encoding:gzip
Content-Length:18936
Content-Type:text/html;charset=UTF-8
Date:Tue, 08 Nov 2016 13:53:16 GMT
Server:nginx/1.4.6 (Ubuntu)
X-Blueocean-Refresher:GjD6b4VWeWwD-----
X-Content-Type-Options:nosniff
X-Text-Size:546612
Request Headers
---------------
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8,zh;q=0.6
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:jenkins.mydomain.com
Pragma:no-cache
Referer:https://jenkins.mydomain.com/blue/organizations/jenkins/MyOrg%2Ffrontend/detail/master/272/pipeline
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Query String Parameters
-----------------------
start:0
Just a note, this error is BO-specific, the traditional Jenkins full log (both HTML & plain text, as in <project>/job/<branch>/<jobNum>/consoleText), show up fine.
My pipeline is wrapped with the following:
timestamps {
node {
wrap([$class: 'AnsiColorBuildWrapper', 'colorMapName': 'XTerm', 'defaultFg': 1, 'defaultBg': 2]) {
well, yeah the later (both request and response header). Anyway it seems a problem more with the AnsiColorBuildWrapper but I will investigate a bit more.
Meanwhile, how does the wrapper create newlines? as \n or with <br/>?
Do you see the same problem with https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/blueocean/branches/master/runs/442/log/?start=0
Samuel Reed
added a comment - It's with `\n`.
The link you posted works fine, because the default user-agent style for text/plain adds the following wrapper, which is not present in my output:
Disabling both the AnsiColor & Timestamper plugins does not fix the issue.
A good fix for this would be to force `text/plain` and ensure that nothing is injecting HTML. For instance, something is injecting anchor tags into my log output, but I don't know what.
Samuel Reed
added a comment - It's with `\n`.
The link you posted works fine, because the default user-agent style for text/plain adds the following wrapper, which is not present in my output:
Disabling both the AnsiColor & Timestamper plugins does not fix the issue.
A good fix for this would be to force `text/plain` and ensure that nothing is injecting HTML. For instance, something is injecting anchor tags into my log output, but I don't know what. Hmm, what I do not understand is that on our dogfood server you see the wrapper but in your instance not.
can you do the following pipeline (in the system you see that problem) and see whether it is the same problem:
node {
stage "hey"
sh "echo yeah"
stage "ping"
sh "ping -c 10 www.spiegel.de"
stage "ho"
sh "echo done"
}
Samuel Reed
added a comment - Yeah, same line break issue. Delivered as HTML but without a `<pre>` wrapper. Here's the output:
Started by user <a href='/user/sreed' class='model-link'>sreed</a> <span style="color:#9A9999">[Pipeline] node </span>Running on master in /var/lib/jenkins/workspace/pipeline-test <span style="color:#9A9999">[Pipeline] { </span><span style="color:#9A9999">[Pipeline] stage (hey) </span>Using the ‘stage’ step without a block argument is deprecated Entering stage hey Proceeding <span style="color:#9A9999">[Pipeline] sh </span>[pipeline-test] Running shell script + echo yeah yeah <span style="color:#9A9999">[Pipeline] stage (ping) </span>Using the ‘stage’ step without a block argument is deprecated Entering stage ping Proceeding <span style="color:#9A9999">[Pipeline] sh </span>[pipeline-test] Running shell script + ping -c 10 www.spiegel.de PING www.spiegel.de (62.138.116.25) 56(84) bytes of data. 64 bytes from 62.138.116.25: icmp_seq=1 ttl=236 time=27.5 ms 64 bytes from 62.138.116.25: icmp_seq=2 ttl=236 time=27.2 ms 64 bytes from 62.138.116.25: icmp_seq=3 ttl=236 time=27.1 ms 64 bytes from 62.138.116.25: icmp_seq=4 ttl=236 time=27.1 ms 64 bytes from 62.138.116.25: icmp_seq=5 ttl=236 time=27.2 ms 64 bytes from 62.138.116.25: icmp_seq=6 ttl=236 time=27.5 ms 64 bytes from 62.138.116.25: icmp_seq=7 ttl=236 time=27.1 ms 64 bytes from 62.138.116.25: icmp_seq=8 ttl=236 time=27.3 ms 64 bytes from 62.138.116.25: icmp_seq=9 ttl=236 time=27.3 ms 64 bytes from 62.138.116.25: icmp_seq=10 ttl=236 time=27.2 ms --- www.spiegel.de ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 27.126/27.284/27.511/0.165 ms <span style="color:#9A9999">[Pipeline] stage (ho) </span>Using the ‘stage’ step without a block argument is deprecated Entering stage ho Proceeding <span style="color:#9A9999">[Pipeline] sh </span>[pipeline-test] Running shell script + echo done done <span style="color:#9A9999">[Pipeline] } </span><span style="color:#9A9999">[Pipeline] // node </span><span style="color:#9A9999">[Pipeline] End of Pipeline </span>Finished: SUCCESS
Samuel Reed
added a comment - Yeah, same line break issue. Delivered as HTML but without a `<pre>` wrapper. Here's the output:
Started by user <a href= '/user/sreed' class= 'model-link' > sreed </a>
<span style= "color:#9A9999" > [Pipeline] node
</span> Running on master in /var/lib/jenkins/workspace/pipeline-test
<span style= "color:#9A9999" > [Pipeline] {
</span> <span style= "color:#9A9999" > [Pipeline] stage (hey)
</span> Using the ‘stage’ step without a block argument is deprecated
Entering stage hey
Proceeding
<span style= "color:#9A9999" > [Pipeline] sh
</span> [pipeline-test] Running shell script
+ echo yeah
yeah
<span style= "color:#9A9999" > [Pipeline] stage (ping)
</span> Using the ‘stage’ step without a block argument is deprecated
Entering stage ping
Proceeding
<span style= "color:#9A9999" > [Pipeline] sh
</span> [pipeline-test] Running shell script
+ ping -c 10 www.spiegel.de
PING www.spiegel.de (62.138.116.25) 56(84) bytes of data.
64 bytes from 62.138.116.25: icmp_seq=1 ttl=236 time=27.5 ms
64 bytes from 62.138.116.25: icmp_seq=2 ttl=236 time=27.2 ms
64 bytes from 62.138.116.25: icmp_seq=3 ttl=236 time=27.1 ms
64 bytes from 62.138.116.25: icmp_seq=4 ttl=236 time=27.1 ms
64 bytes from 62.138.116.25: icmp_seq=5 ttl=236 time=27.2 ms
64 bytes from 62.138.116.25: icmp_seq=6 ttl=236 time=27.5 ms
64 bytes from 62.138.116.25: icmp_seq=7 ttl=236 time=27.1 ms
64 bytes from 62.138.116.25: icmp_seq=8 ttl=236 time=27.3 ms
64 bytes from 62.138.116.25: icmp_seq=9 ttl=236 time=27.3 ms
64 bytes from 62.138.116.25: icmp_seq=10 ttl=236 time=27.2 ms
--- www.spiegel.de ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 27.126/27.284/27.511/0.165 ms
<span style= "color:#9A9999" > [Pipeline] stage (ho)
</span> Using the ‘stage’ step without a block argument is deprecated
Entering stage ho
Proceeding
<span style= "color:#9A9999" > [Pipeline] sh
</span> [pipeline-test] Running shell script
+ echo done
done
<span style= "color:#9A9999" > [Pipeline] }
</span> <span style= "color:#9A9999" > [Pipeline] // node
</span> <span style= "color:#9A9999" > [Pipeline] End of Pipeline
</span> Finished: SUCCESS
strml Logs from blueocean APIs are served based on Accept header. By default with accept header /, logs are served as plain text, with text/html header its served as text/html, with preference to text/plain.
blueocean fetches these logs as plain/text and adds it's own annotation to it while rendering on the UI console.
Sorry, its not clear, which case you are referring to as bug, is it that you are finding HTML tags in plain text log or you find text/html logs not properly HTML formatted? In the later case (that is text/html log), blueocean is serving the log file using standard logging mechanism where log annotators (from different plugins) get a chance to annotate the log. Anyways, blueocean UI does not fetch logs as text/html by design and renders them as plain text at present so html tags do not affect it.
with Accept header / (same would be if you send accept header with text/plain):
$ curl -v https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/blueocean-demo-project/branches/master/runs/15/nodes/5/steps/6/log/ ... > GET /blue/rest/organizations/jenkins/pipelines/blueocean-demo-project/branches/master/runs/15/nodes/5/steps/6/log/ HTTP/1.1 > Host: ci.blueocean.io > User-Agent: curl/7.49.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.9.14 < Date: Tue, 08 Nov 2016 17:09:17 GMT < Content-Type: text/plain;charset=UTF-8 < Transfer-Encoding: chunked < Connection: keep-alive < X-Content-Type-Options: nosniff < X-Blueocean-Refresher: YP9T4GySm2sakhmTUbyS5AsTVSc= < X-Text-Size: 1505 < Cloning the remote Git repository Cloning repository https://github.com/cloudbeers/blueocean-demo-project.git > git init /home/ubuntu/slave/workspace/blueocean-demo-project/master # timeout=10 Fetching upstream changes from https://github.com/cloudbeers/blueocean-demo-project.git > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/cloudbeers/blueocean-demo-project.git +refs/heads/*:refs/remotes/origin/* > git config remote.origin.url https://github.com/cloudbeers/blueocean-demo-project.git # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url https://github.com/cloudbeers/blueocean-demo-project.git # timeout=10 Fetching upstream changes from https://github.com/cloudbeers/blueocean-demo-project.git > git -c core.askpass=true fetch --tags --progress https://github.com/cloudbeers/blueocean-demo-project.git +refs/heads/*:refs/remotes/origin/* > git config remote.origin1.url https://github.com/cloudbeers/blueocean-demo-project.git # timeout=10 Fetching upstream changes from https://github.com/cloudbeers/blueocean-demo-project.git > git -c core.askpass=true fetch --tags --progress https://github.com/cloudbeers/blueocean-demo-project.git +refs/pull/*/head:refs/remotes/origin/pr/* Checking out Revision cef75de9ac5251a3905d14e1f247c0183951d753 (master) > git config core.sparsecheckout # timeout=10 > git checkout -f cef75de9ac5251a3905d14e1f247c0183951d753
Log with text/html accept header:
$ curl -v -H 'Accept: text/html' https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/blueocean-demo-project/branches/master/runs/15/nodes/5/steps/6/log/ ... > GET /blue/rest/organizations/jenkins/pipelines/blueocean-demo-project/branches/master/runs/15/nodes/5/steps/6/log/ HTTP/1.1 > Host: ci.blueocean.io > User-Agent: curl/7.49.1 > Accept: text/html > < HTTP/1.1 200 OK < Server: nginx/1.9.14 < Date: Tue, 08 Nov 2016 17:10:08 GMT < Content-Type: text/html;charset=UTF-8 < Transfer-Encoding: chunked < Connection: keep-alive < X-Content-Type-Options: nosniff < X-Blueocean-Refresher: YP9T4GySm2sakhmTUbyS5AsTVSc= < X-ConsoleAnnotator: QOxFEOAxBv8dXPfV+TNRO4MyPWuGfqZmS8+wl9m5/TNXxLVqSX5KA0ipf49CdVlMIxCjWClDfamu2Kt/2RQGkCM9Im7DAps9WsWD7sdc9/dusTYH2eSWdKvGddaAvTNh < X-Text-Size: 1505 < Cloning the remote Git repository Cloning repository <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> > git init /home/ubuntu/slave/workspace/blueocean-demo-project/master # timeout=10 Fetching upstream changes from <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> +refs/heads/*:refs/remotes/origin/* > git config remote.origin.url <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> # timeout=10 Fetching upstream changes from <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> > git -c core.askpass=true fetch --tags --progress <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> +refs/heads/*:refs/remotes/origin/* > git config remote.origin1.url <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> # timeout=10 Fetching upstream changes from <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> > git -c core.askpass=true fetch --tags --progress <a href='https://github.com/cloudbeers/blueocean-demo-project.git'>https://github.com/cloudbeers/blueocean-demo-project.git</a> +refs/pull/*/head:refs/remotes/origin/pr/* Checking out Revision cef75de9ac5251a3905d14e1f247c0183951d753 (master) > git config core.sparsecheckout # timeout=10 > git checkout -f cef75de9ac5251a3905d14e1f247c0183951d753
I am fetching the full log, via the blueocean link in the UI, from the above link as in the description.
The issue is that Chrome, by default, sends:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
If any plugin has modified the output, blueocean sends back `text/html` but does not correctly add <br /> tags or wrap in a <pre>, thus causing the lack of newlines in the rendered output.
There are two possible fixes:
1. Force text/plain, which could be awkward for plugins that modify the output (colors, anchors, etc will just show up as raw text)
2. If serving `text/html` due to injection from plugins or elsewhere, wrap the output in the standard text/plain wrapper that Chrome uses:
<html><head></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">
{{content}}
</pre></body></html>
Samuel Reed
added a comment - - edited I am fetching the full log, via the blueocean link in the UI, from the above link as in the description.
The issue is that Chrome, by default, sends:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
If any plugin has modified the output, blueocean sends back `text/html` but does not correctly add <br /> tags or wrap in a <pre>, thus causing the lack of newlines in the rendered output.
There are two possible fixes:
1. Force text/plain, which could be awkward for plugins that modify the output (colors, anchors, etc will just show up as raw text)
2. If serving `text/html` due to injection from plugins or elsewhere, wrap the output in the standard text/plain wrapper that Chrome uses:
<html><head></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">
{{content}}
</pre></body></html>
Ill find some time for someone to look at this one in the next few sprints.
teilo thanks we've seen this too. We are going to look at it in the next sprint 
if it is shown as HTML - will it behave correctly or will console annotators mess with it? If so - best to show plain text and probably show the classic console view for those that want to use annotators for now?
EDIT: oh that plain wrapped like strml suggested could be good to - worth a try.
Got same problem, unable to read logs as a result ) looks like at least Firefox treats full log as HTML code and renders a mess
jamesdumay is this the right place to just report that "show full logs" button opens the tab with logs that are being rendered as HTML in Firefox ?
kamikaze that one has been fixed in master and will be out in next release.
michaelneale I have latest BlueOcean 1.0.0-b23 . Logs are still being rendered as a one line text that takes the whole screen. At least in Firefox
Thanks for the report strml. Would you happen to have a screenshot you could share of the log?