探究浏览器处理PDF文件时自动下载与预览的行为原因

背景

我们的系统使用Minio进行文件存储,并通过服务端提供统一的上传接口。此外,我们还使用Nginx进行服务代理。前端需求中包括对上传PDF文件的预览功能。

问题描述

在前端预览PDF文件时,我们采用window.open方法在新窗口中打开文件。期望的行为是浏览器能直接预览这些PDF文件。然而,在Chrome浏览器(版本号小于116)中,我们观察到了不一致的行为:

  • 可预览的PDF : 这些是单独上传的PDF文件,服务端返回的Content-Type为application/pdf。Chrome能够直接预览这种类型的文件。

  • 不可预览的PDF : 这些是打包成ZIP文件进行批量上传的PDF文件。服务端返回的Content-Type为application/octet-stream,导致Chrome会直接下载这些文件。

分析与解决方案

针对上述问题,我们有以下疑问:

  • 为什么同一个文件存储服务会返回不同的Content-Type?

可能的原因:

  1. Nginx配置问题 : 可能对不同的PDF文件设置了不同的Content-Type头信息。

  2. 上传服务问题 : 在查看批量上传和单个上传的代码后,发现批量上传中有以下代码设置Content-Type:

java 复制代码
FileItem item = new DiskFileItemFactory().createItem(
        file.getName() , 
        "application/octet-stream" , 
        true , 
        file.getName()
);

解决方案:

  • 调整Nginx的配置,确保返回的Content-Type头信息为application/pdf。

  • 修改相关的Java代码,以设置正确的Content-Type。

结语

祝大家周末愉快!

相关推荐
脚本自动化开发8 小时前
存储涨价后,磐镭WO5迷你主机值得买吗
后端
一只爱撸猫的程序猿10 小时前
我看着一个 AI 引擎在 14 天里,从"记忆"走进了"搜索"
人工智能·后端·架构
LucianaiB11 小时前
【元宝搜索开发者征文大赛】AI时代,学得慢就不用学?用元宝搜索打造一个教程保质期,确保每一个教程符合你的现状
前端·人工智能·ai编程
excel11 小时前
JavaScript 对象池:减少高频对象创建与 GC 压力
前端
陈随易13 小时前
纯 Go 写的 JS 引擎,跑分超过了 C 语言的 QuickJS
前端·后端·程序员
卷无止境13 小时前
RAGFlow 项目全景报告:从文档解析引擎到 Agent 原生数据库
后端·python
小Z先生14 小时前
我用 Go + 系统 WebView 写了个纯本地 Postman:不装 Electron、不连云端
后端·github
子兮曰14 小时前
Chrome 权限元素实战:144 与 151 的渐进增强写法
前端·javascript·chrome
IT_陈寒14 小时前
Redis连接池泄漏那次,我差点把生产环境搞崩了
前端·人工智能·后端
强尼银手14 小时前
我花一天做了个格斗游戏原型,判定全对,然后被「美术」劝退了
前端·javascript