Tvheadend中录制文件下载时HTTP响应头换行符处理缺陷分析

问题背景

在Tvheadend媒体服务器(v4.3开发版)中，当用户尝试通过HTTP接口下载包含换行符的录制文件时，系统生成的Content-Disposition响应头存在格式问题。该缺陷会导致HTTP响应不符合RFC规范，使得标准HTTP客户端(如cURL)和网络中间件(如HAProxy)无法正确处理响应。

技术细节分析

问题表现

当录制文件的元数据中包含换行符时(常见于多行描述的EPG电子节目指南数据)，这些换行符会被直接插入到HTTP响应头的filename参数中。根据HTTP/1.1规范(RFC 7230)，头字段必须位于单行，且以冒号分隔字段名和字段值。

错误示例的响应头片段：

Content-Disposition: attachment; filename="示例节目 - 第一行
第二行描述
第三行.mkv"

根本原因

经代码审查发现，问题源于webui.c文件中的HTTP响应生成逻辑未能对文件名中的特殊字符进行适当处理。特别是当用户禁用"移除文件名中不安全字符"选项时，换行符会被保留在最终输出的HTTP头中。

影响范围

该缺陷主要影响以下场景：

1. 使用Matroska格式录制的节目
2. EPG数据中包含多行描述的节目
3. 配置了保留原始文件名的录制配置

解决方案

临时解决方案

用户可通过以下方式临时规避问题：

1. 在录制配置中启用"移除所有不安全字符"选项
2. 避免使用包含换行符的EPG数据源

永久修复方案

从技术实现角度，应在HTTP头生成阶段对所有控制字符进行转义或过滤。具体可采取以下措施：

1. 在输出HTTP头前，使用字符串处理函数替换所有换行符为空格
2. 对RFC 5987规定的filename*参数中的特殊字符进行百分号编码
3. 添加HTTP头生成时的完整性检查

最佳实践建议

对于类似多媒体服务器的开发，建议：

1. 所有输出到HTTP头的内容都应经过严格的字符过滤
2. 实现自动化的HTTP响应验证机制
3. 对用户提供的元数据保持防御性编程态度
4. 考虑采用现有的HTTP库处理头字段编码，而非手动拼接

该问题虽然看似简单，但反映了在多媒体系统开发中处理用户生成内容时的常见安全陷阱，值得开发者引以为鉴。