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

背景

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

问题描述

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

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

  • 不可预览的PDF : 这些是打包成ZIP文件进行批量上传的PDF文件。服务端返回的Content-Typeapplication/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

结语

祝大家周末愉快!

相关推荐
J船长14 分钟前
烂笔头扫盲:Embedding 与语义匹配:从概念到 pgvector 落地
前端
Conan在掘金18 分钟前
鸿蒙 ArkUI 进阶:@Extend 和 @Styles,把样式也抽成「乐高块」的正确姿势
后端
orient26 分钟前
为什么需要并发编程
后端
Cosolar32 分钟前
AI Agent 架构原理详解:从一次提问到任务完成的完整闭环
人工智能·后端·架构
Conan在掘金40 分钟前
鸿蒙 ArkUI 深水区:Stage 模型多维状态,从「组件内」跳到「应用级」的分水岭
后端
程序员黑豆1 小时前
鸿蒙应用开发之模拟器安装与使用教程
前端·harmonyos
王莎莎1 小时前
MCP 解决的是工具接入,科研 Agent 还缺的是科学证据接口标准化
前端·人工智能
长栎1 小时前
用AI优化Redis缓存失效,我把热key问题想简单了
后端
面试鸭1 小时前
我说我们做 Agent 从来不怕死循环,面试官调出兜底日志:“第 47 次强制终止,是你半夜爬起来按停的?”
后端·面试·求职
小小猪的春天1 小时前
团队级 Code Review Skill 实践:4个人、4个AI、1套规则,CR从找bug变成做决策
后端·架构