php – 未正确设置内容长度标头

我有一个php脚本(实际上是https://drupal.org/project/file_force),它通过向响应中添加正确的标题来强制点击链接的用户下载该链接.

此链接在90％的时间内都能正常工作.有时会传递不正确的内容长度,因此用户显然会截断文件.错误在特定文件上一致地发生,但如果重新上载这些文件,则错误可能不会出现在新实例上,这使我认为这不是文件的问题,而是某个地方的缓存.所以我每次都运行clearstatcache()无济于事.奇怪的是,php正在传递正确的文件大小,或者说它是在我传递它插入日志文件的字符串时.

这是相关的代码：

  clearstatcache();
  return array(
    'Content-Type: ' . $mimeinfo,
    'Content-Disposition: ' . $disposition . '; filename="' . basename($filepath) . '";',
    // Content-Length is also a good header to send, as it allows the browser to
    // display a progress bar correctly.
    // There's a trick for determining the file size for files over 2 GB. Nobody
    // should be using this module with files that large, but… the sprintf()
    // trickery makes sure the value is correct for files larger than 2GB. See
    // note at http://php.net/filesize
    'Content-Length: ' . sprintf('%u', filesize($filepath)),
  );

来自sprintf(‘％u’,filesize($filepath))的示例输出在一个不起作用的文件上是2682059,当浏览器看到它时,它以某种方式被转换为1740048.

我试过删除sprintf函数无济于事.
我也尝试过根本不包括Content-Length声明,但是无论如何,有人正在附加不正确的值.最后一条证据可能表明其他一些代码覆盖了我在这里设置的内容标题,但它似乎只留下我在上面的代码中更改的任何其他标题来测试该理论.

有什么想法去哪儿看？

解决方法:

我解决了这个问题.

事实证明,Drupal中的另一个模块正在添加自己的内容长度标头并从数据库而不是文件直接获取值(奇怪),并且它正在下游发生.通过颠倒模块在标题上的顺序,问题就消失了.我已经针对违规模块提交了一份错误报告.

标签：php,http-headers,drupal,content-length,http-content-length
来源： https://codeday.me/bug/20190629/1324753.html