|
||||||||
|
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/groups/opt_out.
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:
1) 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
2) Embedded Firefox viewer (based on pdf.js)
Environment:
Ubuntu Raring
Firefox 22
Jenkins 1.521
PDF file: Not linearized, 49KB
Result:
PDF displays correctly
3) 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
4) 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.