-
Bug
-
Resolution: Fixed
-
Major
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.
- is related to
-
JENKINS-33195 Can't open PDF artifact on Chrome/Safari integrated viewers
-
- Closed
-
[JENKINS-13125] HTTP Content-Range Header one byte past file length and missing "bytes" unit
Component/s | New: www [ 15484 ] | |
Component/s | Original: core [ 15593 ] |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Resolution | Original: Fixed [ 1 ] | |
Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Reproduced with Jenkins 1.461 running on Winstone.
The archived file's length is 1716 bytes.
It seems that "last-byte-pos" in Content-Range header is always bigger by 1 byte.