Reputation: 21
I use mozilla's pdf.js library to render a pdf in my application. It uses byte-range requests for the same. I know that the requests for the first and the last set of bytes are made first for metadata purposes. But the range of the last set of bytes differs with respect to the pdf. How is the range for the last set of bytes identified and set? Also the first set of bytes is obtained with 200 OK status. I want to know why 200 and not 206 partial content status.
Upvotes: 1
Views: 666
Reputation: 2691
I know that the requests for the first and the last set of bytes are made first for metadata purposes.
It partially incorrect: even if it is reaching the xref/metadata, it is loading last chunk of PDF. File is logically split into chunks of 65536 bytes (see https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L32)
But the range of the last set of bytes differs with respect to the pdf.
PDF.js loads only whole chunks (for efficiency), probably except the incomplete last one. Hence range of last chunk size might be different for different PDF size.
Also the first set of bytes is obtained with 200 OK status. I want to know why 200 and not 206 partial content status.
Depends on the browser you are talking about. For browsers with streaming support (for now it is only Firefox), PDF.js continues fetching data in addition to range requests. Some browsers (Safari and old Chrome) have cache defect: it is reporting 200 for cached files, even for range range request.
Upvotes: 1