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

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core

      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.

          [JENKINS-13125] HTTP Content-Range Header one byte past file length and missing "bytes" unit

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1690
          [FIXED JENKINS-13125] Fixed a bug in Content-Range header handling (Revision 50593fb7aa158aa1b80a28159146d2f970ad1e98)

          Result = UNSTABLE
          Kohsuke Kawaguchi : 50593fb7aa158aa1b80a28159146d2f970ad1e98
          Files :

          • changelog.html
          • core/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #1690 [FIXED JENKINS-13125] Fixed a bug in Content-Range header handling (Revision 50593fb7aa158aa1b80a28159146d2f970ad1e98) Result = UNSTABLE Kohsuke Kawaguchi : 50593fb7aa158aa1b80a28159146d2f970ad1e98 Files : changelog.html core/pom.xml

          dogfood added a comment -

          Integrated in jenkins_ui-changes_branch #26
          [FIXED JENKINS-13125] Fixed a bug in Content-Range header handling (Revision 50593fb7aa158aa1b80a28159146d2f970ad1e98)

          Result = SUCCESS
          Kohsuke Kawaguchi : 50593fb7aa158aa1b80a28159146d2f970ad1e98
          Files :

          • core/pom.xml
          • changelog.html

          dogfood added a comment - Integrated in jenkins_ui-changes_branch #26 [FIXED JENKINS-13125] Fixed a bug in Content-Range header handling (Revision 50593fb7aa158aa1b80a28159146d2f970ad1e98) Result = SUCCESS Kohsuke Kawaguchi : 50593fb7aa158aa1b80a28159146d2f970ad1e98 Files : core/pom.xml changelog.html

          Roland Schulz added a comment -

          I just upgraded to 1.463 but the Chrome internal PDF viewer still gets stuck on a PDF from Jenkins. Thus this doesn't seem to be fixed.

          Roland Schulz added a comment - I just upgraded to 1.463 but the Chrome internal PDF viewer still gets stuck on a PDF from Jenkins. Thus this doesn't seem to be fixed.

          Eric Blom added a comment -

          Like Rolland, we are also running in to this problem on 1.480.3.

          Eric Blom added a comment - Like Rolland, we are also running in to this problem on 1.480.3.

          Eric Blom added a comment -

          I hope I'm not causing a problem here by reopening this issue as I just registered for an account here and might be violating protocol. However, like Roland we still see this issue in v1.480.3.

          Eric Blom added a comment - I hope I'm not causing a problem here by reopening this issue as I just registered for an account here and might be violating protocol. However, like Roland we still see this issue in v1.480.3.

          Same problem in 1.504.

          Pei-Tang Huang added a comment - Same problem in 1.504.

          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

          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.

          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

          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

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

              Created:
              Updated:
              Resolved: