|
||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
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.