OmniSharp项目中的System.Uri解析问题分析与解决方案

问题背景

在OmniSharp项目中，开发团队发现了一个与System.Uri解析相关的严重问题。这个问题主要影响使用Perforce for VS Code扩展或在开发容器(devcontainer)环境中运行VS Code的用户。当这些用户尝试打开某些文件时，服务器会崩溃，导致整个功能无法使用。

问题本质

问题的核心在于System.Uri类对某些RFC规范允许的URI格式进行了额外的验证，导致解析失败。具体表现为：

1. 当主机名(hostname)中包含sub-delims字符时（如#或+），System.Uri会抛出UriFormatException异常
2. 这种情况在两种常见场景下出现：
   • Perforce for VS Code扩展有时会在主机名中使用百分号编码的#
   • 在开发容器环境中运行的VS Code提供的Notebook URI可能包含+字符

技术影响

这个问题对系统的影响是多方面的：

1. 服务器崩溃：当尝试打开包含这些特殊URI的文件时，服务器无法处理didOpen请求而崩溃
2. 功能中断：导致整个语言服务器功能不可用
3. 用户体验下降：用户无法正常使用代码编辑和智能提示功能

解决方案探讨

开发团队提出了几种可能的解决方案：

1. 推动运行时改进

建议在.NET运行时中添加一个完全符合RFC规范的解析模式，不进行额外的主机名验证。但这种方法：

• 需要较长时间才能实现
• 只适用于新版本的运行时
• 最早只能在切换到.NET 10运行时后才能使用

2. 完全替换System.Uri

像OmniSharp/csharp-language-server-protocol项目那样，完全移除System.Uri的使用，实现自定义的URI解析器。这种方案：

• 提供了最大的灵活性
• 但实现复杂度高
• 需要长期维护自定义解析器

3. 部分替换System.Uri

仅在协议序列化类型中移除System.Uri的使用，改用字符串或字符串包装器。只有在需要解析URI获取文件路径时才调用System.Uri。这种折中方案：

• 允许处理基本的文本同步请求
• 防止服务器完全崩溃
• 只有特定请求会失败
• 实现相对简单

技术决策

基于当前情况，开发团队暂时将问题标记为"Backlog"，优先考虑以下方向：

1. 建议Perforce扩展更新其URI生成逻辑，避免产生不符合System.Uri验证规则的URI
2. 如果无法从源头上解决问题，再考虑在OmniSharp中实现更复杂的解决方案

开发者建议

对于遇到类似问题的开发者，可以考虑以下临时解决方案：

1. 检查并修改Perforce配置，避免在URI中使用特殊字符
2. 在开发容器环境中，检查VS Code生成的URI格式
3. 暂时禁用相关扩展以恢复功能

这个问题展示了在开发工具链中，不同组件间的规范兼容性可能带来的挑战，也提醒开发者在处理URI时需要特别注意格式兼容性问题。