ASP.NET WebForms绑定SSL后文件下载与SSRS报表功能失效排查

• 服务器系统：Windows Server 2016
• Web服务：IIS 10
• 部署站点：ASP.NET WebForms 应用
• 已装组件：通配符SSL/TLS证书、IIS URL Rewrite 2.1
• 已配置规则：在站点根目录web.config中设置HTTP请求自动跳转HTTPS的重写规则
• 认证逻辑：采用数据库比对式的自定义简易用户认证，未接入正式认证框架，无标准认证令牌机制

未绑定SSL证书时，站点的文件下载、SSRS运行时生成的内嵌PDF报表显示功能在所有主流浏览器下运行完全正常；绑定SSL证书后，跨浏览器出现统一异常：

• Chrome/Chromium内核（Edge、Opera同逻辑匹配该表现）：
  • 完全关闭所有Chrome实例后首次访问站点时，文件下载报Failed - Network error，此时实际下载下来的内容为站点网页源码，并非目标下载文件
  • 触发一次首次异常后，保持任意一个Chrome实例处于打开状态，后续新开窗口、新开标签页、重试下载、断点续传均可正常使用；SSRS报表首次加载报Failed to load PDF document，点击重载后可正常显示
  • 两类功能任意一类触发首次异常后，当前浏览器整个生命周期内，另一类功能也可正常运行，不再复现异常
• Firefox浏览器：访问两类功能均报Secure Connection Failed，手动修改高级配置network.http.spdy.enabled.http2为false后可永久恢复正常
• IE11浏览器：两类功能全流程无任何异常
• Mac端Safari浏览器：下载的zip压缩包被系统识别为加密文件，实际服务端代码未对压缩包设置任何密码

所有异常的核心触发源为IIS 10 on Windows Server 2016 内置HTTP/2实现的兼容性缺陷：

• 该版本HTTP/2栈对非标准无状态认证流程的连接预热逻辑处理存在bug，首次建立HTTPS连接时，会错误拆分301/302重定向响应、SSRS流式输出的PDF帧，导致浏览器拿到的首个响应片段不是目标文件二进制内容，而是跳转页的HTML源码；一旦首次连接握手完成（即使握手过程存在帧错位），后续所有请求复用该HTTP/2连接时就不会再出现异常，完全匹配“必须关闭所有Chrome实例才会复现、触发一次异常后后续全正常”的特征
• Firefox对该版本IIS的HTTP/2 TLS协商兼容度更差，直接握手失败报安全连接错误，关闭HTTP2改用HTTP/1.1协议后即可恢复正常
• IE11默认不对该版本IIS上的HTTPS站点启用HTTP/2连接，全程走HTTP/1.1协议通信，因此完全无异常
• 站点输出下载响应时未显式声明核心响应头，叠加HTTP/2的帧拆分bug，导致Mac端Safari拿到的zip文件流出现帧头错位，系统解压时识别错误文件结构，误判为带密码的加密压缩包

所有调整均在服务端完成，不需要用户修改任何浏览器设置，可兼容全主流浏览器：

1. 协议层调整：
   • 修正IIS的TLS加密套件优先级，保证TLS 1.2及以上版本的加密套件优先级高于旧协议；如果调整后仍有偶发异常，可直接在站点HTTPS绑定层面关闭HTTP/2自动协商，强制所有客户端走HTTP/1.1协议通信，不会影响现有HTTP跳转HTTPS的重写规则
2. 应用层响应修正：
   • 修正web.config中的URL重写跳转规则，为所有重定向响应追加Cache-Control: no-cache响应头，避免浏览器把重定向响应错缓存为下载文件
   • 统一规范文件下载、SSRS报表输出的响应头逻辑：
     • 下载响应必须显式指定Content-Type、Content-Disposition、Content-Length三个核心头，不依赖IIS默认MIME类型推断
     • SSRS内嵌PDF输出时，等PDF内容全部生成完成后再一次性输出完整响应，关闭响应的分块传输编码，避免流式输出时被HTTP/2栈拆错帧
3. 认证逻辑补全：
   • 为自定义认证流程补充固定的会话Cookie标识，不要完全依赖纯无状态的数据库比对逻辑，让浏览器在首次建立HTTPS连接时就能正确匹配会话上下文，避免连接建立初期的响应错位

内容的提问来源于stack exchange，提问作者InTech97