Question

我创建了一个基于System.Net.HttpListener的 WebDav 服务器，通过虚拟文件系统提供对存储在数据库中的（现有）文档库的访问。此组件的目的是提供对存储文档的文件级访问，这些文档可以作为Windows下的网络驱动器附加，因此使用不同的客户端是不可能的。

数据库将文档存储在类似文件系统的层次结构中，因此我将容器映射为WebDav集合（在客户端显示为文件夹），一切似乎都很好，直到我发现我的用户使用具有尾随句点的集合在他们的名字。请注意，这是一款已投入生产十多年的产品，因此引入新的命名约定是不可能的。由于HttpListener使用标准的C＃System.Uri类来提供请求URL，并且该类吞下URL的尾随句点。

https://www.something.com/xyz.

例如

成为

https://www.something.com/xyz

本身就足够糟糕，但也可以通过检查期间扩展文件夹名称来解决。但问题比这更糟糕，因为System.Uri类不仅会破坏路径的最后一段，而且还会破坏所有路段，所以

https://www.something.com/xyz./knm/xxx.doc

变为

https://www.something.com/xyz/knm/xxx.doc

和

https://www.something.com/xyz./knm/./qwe./xyz.doc

变为

https://www.something.com/xyz/knm/qwe/xyz.doc

我无法处理。

到目前为止我的尝试......

通过将其替换为“％2E”来逃避期限不起作用，因为它不会在Windows资源管理器和Total Commander等客户端中转义。
返回PROPFIND href节点中的转义版本和dislpayname节点中的文字版本不起作用，因为大多数客户都会忽略“displayname”。
this answer中描述的解决方法似乎不起作用。（它没有做任何事情。同一个线程中的另一个答案提供了一种方法来破解System.Uri类的某个实例，但由于该实例是由HttpListener创建的 - 或者它的一个基础机制 - 真的对我没有帮助。）

在2008年的一个帖子中，我发现了以下引用

这是一个已知的错误。不久前在这些论坛上实际讨论过这个问题。一位MSFT员工承认了这个问题，并表示将考虑将来的版本。

任何人都可以为此问题提供变通方法或实际解决方案吗？

Answer 1

您使用的是哪个版本的.NET Framework？我创建了一个示例应用程序并使用包含点的字符串初始化了System.URI。 .NET 4.0删除了这些点，但是任何更新的都留下了它们。

您可以使用较新版本的.NET吗？

class Program
{
    static void Main(string[] args)
    {
        var uri = new Uri("http://localhost:8080/one./two./three./my.doc");

        Console.WriteLine(uri.ToString());
    }
}

HttpListener吞下了URL尾随句点

1 个答案: