Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: core
-
Labels:
-
Similar Issues:
Description
Downloading a PDF artifact using Chrome (17.0.963.79 m on Windows) the HTTP header for the last partial entity-body sent back by Jenkins contains:
Content-Range: 2613923-2646691/2646691\r\n
I believe this is wrong according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16 . I believe the last range should be 2613923-2646690/2646691, because the numbers are 0-indexed.
I'm not sure whether this is caused by this or is a separate issue, but Chrome keeps requesting the same last partial segment and Jenkins returns the same one in an endless loop. Thus Chrome is stuck loading the PDF at 100% in the endless loop. This only happens with the Chrome embedded PDF viewer. The file downloads correctly with "Save as".
Update: It now appears that the content-range unit "bytes" is missing from the header.
Attachments
Issue Links
- is related to
-
-
- Closed
-
Activity
I've got exactly the same PDF problem here on chrome 28.0 (linux x64) with jenkins 1.517
Christian Simon
added a comment - I've got exactly the same PDF problem here on chrome 28.0 (linux x64) with jenkins 1.517 I am using Jenkins 1.521 from the Jenkins APT repository on Ubuntu. I am getting a very similar symptom to the one described here i.e. when trying to view a PDF in the embedded Chrome viewer it is failing.
I have done a couple of experiments which lead me to believe that Jenkins is simply failing to include the units i.e. "bytes" in the content-range header. Is this possibly the problem?
I notice that the headers shown in previous comments don't have a unit so in my reading they don't match the production for content-range-spec in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.16 and bytest-unit in http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html section 3.12.
My experiments:
Embedded Chrome viewer
Environment:
Ubuntu Raring
Chrome 28
Jenkins 1.521
PDF file: Not linearized, 49KBResult:
PDF loading progress bar reaches 100% but no pages are shown
Embedded Firefox viewer (based on pdf.js)
Environment:
Ubuntu Raring
Firefox 22
Jenkins 1.521
PDF file: Not linearized, 49KBResult:
PDF displays correctly
Standalone pdf.js
Environment:
Ubuntu Raring
Firefox 22
pdf.js mozilla-pdf.js-v0.5.5-1204-g81fa4a0
Jenkins 1.521
PDF file: Not linearized, 49KBResult:
PDF progress bar reaches about 15% and no pages are ever displayed, Javascript exception
Patched standalone pdf.js
Environment:
Ubuntu Raring
Firefox 22
pdf.js mozilla-pdf.js-v0.5.5-1204-g81fa4a0 (patched, see below)
Jenkins 1.521
PDF file: Not linearized, 49KBResult:
PDF displays correctly
Explanation:
After looking into the Javascript exception above, I tried a small patch to how pdf.js was parsing the header
diff -ru a/pdfjs/src/network.js b/pdfjs/src/network.js
--- a/pdfjs/src/network.js 2013-07-01 17:29:31.000000000 +0100
+++ b/pdfjs/src/network.js 2013-07-11 15:33:06.000000000 +0100
@@ -187,6 +187,9 @@
if (xhrStatus === PARTIAL_CONTENT_RESPONSE) {
var rangeHeader = xhr.getResponseHeader('Content-Range');
var matches = /bytes (\d+)-(\d+)\/(\d+)/.exec(rangeHeader);
+ if (matches == null) {
+ var matches = /(\d+)-(\d+)\/(\d+)/.exec(rangeHeader);
+ }
var begin = parseInt(matches[1], 10);
pendingRequest.onDone({
begin: begin,
I also tried downloading the artifacts and serving them up from a simple Apache HTTPD. The embedded Chrome viewer, in fact every test, worked fine.
James Ascroft-Leigh
added a comment - - edited I am using Jenkins 1.521 from the Jenkins APT repository on Ubuntu. I am getting a very similar symptom to the one described here i.e. when trying to view a PDF in the embedded Chrome viewer it is failing.
I have done a couple of experiments which lead me to believe that Jenkins is simply failing to include the units i.e. "bytes" in the content-range header. Is this possibly the problem?
I notice that the headers shown in previous comments don't have a unit so in my reading they don't match the production for content-range-spec in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.16 and bytest-unit in http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html section 3.12.
My experiments:
Embedded Chrome viewer
Environment:
Ubuntu Raring
Chrome 28
Jenkins 1.521
PDF file: Not linearized, 49KB
Result:
PDF loading progress bar reaches 100% but no pages are shown
Embedded Firefox viewer (based on pdf.js)
Environment:
Ubuntu Raring
Firefox 22
Jenkins 1.521
PDF file: Not linearized, 49KB
Result:
PDF displays correctly
Standalone pdf.js
Environment:
Ubuntu Raring
Firefox 22
pdf.js mozilla-pdf.js-v0.5.5-1204-g81fa4a0
Jenkins 1.521
PDF file: Not linearized, 49KB
Result:
PDF progress bar reaches about 15% and no pages are ever displayed, Javascript exception
Patched standalone pdf.js
Environment:
Ubuntu Raring
Firefox 22
pdf.js mozilla-pdf.js-v0.5.5-1204-g81fa4a0 (patched, see below)
Jenkins 1.521
PDF file: Not linearized, 49KB
Result:
PDF displays correctly
Explanation:
After looking into the Javascript exception above, I tried a small patch to how pdf.js was parsing the header
diff -ru a/pdfjs/src/network.js b/pdfjs/src/network.js
--- a/pdfjs/src/network.js 2013-07-01 17:29:31.000000000 +0100
+++ b/pdfjs/src/network.js 2013-07-11 15:33:06.000000000 +0100
@@ -187,6 +187,9 @@
if (xhrStatus === PARTIAL_CONTENT_RESPONSE) {
var rangeHeader = xhr.getResponseHeader( 'Content-Range' );
var matches = /bytes (\d+)-(\d+)\/(\d+)/.exec(rangeHeader);
+ if (matches == null ) {
+ var matches = /(\d+)-(\d+)\/(\d+)/.exec(rangeHeader);
+ }
var begin = parseInt(matches[1], 10);
pendingRequest.onDone({
begin: begin,
I also tried downloading the artifacts and serving them up from a simple Apache HTTPD. The embedded Chrome viewer, in fact every test, worked fine. - The RFC is clear that the string "bytes" is required as part of a Content-Range header.
- I verified that after adding "bytes", Chrome downloads the PDF correctly. So I agree with the previous poster that the missing "bytes" is the problem. (Thanks much for the hypothesis - it helped me a lot!)
- I note that Winstone itself emits "Content-Range" including the word "bytes".
- I created a patch for stapler, which is what Jenkins is using. See https://github.com/stapler/stapler/pull/26.
Vince Del Vecchio
added a comment -
The RFC is clear that the string "bytes" is required as part of a Content-Range header.
I verified that after adding "bytes", Chrome downloads the PDF correctly. So I agree with the previous poster that the missing "bytes" is the problem. (Thanks much for the hypothesis - it helped me a lot!)
I note that Winstone itself emits "Content-Range" including the word "bytes".
I created a patch for stapler, which is what Jenkins is using. See https://github.com/stapler/stapler/pull/26 .
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/ad93581104dfe58cf0373322166893a614c530df
Log:
[FIXED JENKINS-13125 JENKINS-20074]
Incorporated Stapler 1.222 to pick up fixes
Same problem in 1.504.