Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13125

HTTP Content-Range Header one byte past file length and missing "bytes" unit

    Details

    • 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

            Activity

            Hide
            tang Pei-Tang Huang added a comment -

            Same problem in 1.504.

            Show
            tang Pei-Tang Huang added a comment - Same problem in 1.504.
            Hide
            simonswine Christian Simon added a comment -

            I've got exactly the same PDF problem here on chrome 28.0 (linux x64) with jenkins 1.517

            Show
            simonswine Christian Simon added a comment - I've got exactly the same PDF problem here on chrome 28.0 (linux x64) with jenkins 1.517
            Hide
            jwal 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.

            Show
            jwal 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.
            Hide
            vdelvecc 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.
            Show
            vdelvecc 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 .
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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

              People

              • Assignee:
                Unassigned
                Reporter:
                rschulz Roland Schulz
              • Votes:
                5 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: