我们正在使用PDF的应用程序,但由于客户使用的PDF大小,我们遇到了缓存问题。决定尝试流式传输/使用范围请求来逐步下载PDF。
以下是我看到的内容:
accept-ranges: bytes
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type, body, Content-Length, Accept-Ranges, Range
access-control-allow-methods: GET,POST,PUT,DELETE
access-control-allow-origin: http://example.test
access-control-max-age: 1000
cache-control: max-age=31536000
content-length: 185124353
content-type: application/pdf
date: Thu, 05 Dec 2019 14:03:42 GMT
etag: "some-etag-that-works-nicely"
因为我现在是在本地运行,所以有很多CORS。在考虑将其推送到开发环境之前,我认为我们已经添加了所有必需的头文件,使PDF.js能够检测到我们支持范围调用,但似乎无法正常工作。
当我深入研究PDFJS-dist/build/pdf.js
文件的第23744
行(v2.3.200
)时,我看到了这个:
if (getResponseHeader('Accept-Ranges') !== 'bytes') {
return returnValues;
}
这让我想到,也许getResponseHeader()
是区分大小写的,在某些情况下,我无法让API以我们习惯的混合大小写形式响应其标头。因此,我决定对其进行一些修改,使其返回值为allowRangeRequests = true
。
这有点奏效,然后我看到了一个与上面相同的标头的200 OK
(在本地工作时经过OPTIONS
后应该被取消,但实际上没有),接着是一堆新的调用,带有增量的range: byte=0-65000
等标头,看起来像这样:
REQUEST
range: bytes=0-65535
//...and other headers of course, omitted for brevity.
RESPONSE
accept-ranges: bytes
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type, body, Content-Length, Accept-Ranges, Range
access-control-allow-methods: GET,POST,PUT,DELETE
access-control-max-age: 1000
cache-control: max-age=31536000
content-length: 65536
content-type: application/pdf
所以,这也为我提供了一个实际工作的PDF(或者至少是几页)的视图;因此,这表明它至少部分地起作用。
现在,为什么我需要“破解”这个,我缺少哪些头信息,以便让PDF.js检测到我们实际上支持范围,因为它似乎已经正确实现了?这是否也是导致它不会在没有range: bytes=0-65535
的情况下取消初始获取的原因,因为另一个“范围支持检测”的部分呢?