当我们（真的 是 butcher 博士 ）制作 swift 到 webdav 代理时 ，架构很重要。前两次构建代理的尝试提出了需要解决的技术和架构问题。例如，只要文件不大，我们的第二次尝试就很有效。但正如对象存储用户所知，有时您需要处理大文件。
验证
webdav 需要使用用户名和密码进行身份验证才能正常工作。另一种身份验证形式 digest authentication 需要访问我们没有的 md5 版本的密码。
当 webdav 客户端尝试针对 webdav 端点进行身份验证时，它将传入用户名和密码。为了让代理与 swift 通信，它需要一个令牌。为了避免为每个请求与 keystone 通信，令牌和一些其他信息存储在 memcached 中。
如果令牌过期或无效，代理服务将要求 webdav 客户端重新进行身份验证。
项目（租户）
webdav 能够提供用户名和密码。 openstack 将资产范围限定为项目，以前称为租户。为了处理将所有 3 条信息传递给 swift，项目 ID 收集在 url 中。例如，
https://webdav-endpoint.region.example.com/1234/
各个代理实例配置为与特定区域一起使用。每个受支持的区域都需要代理设置。这使设置可以毫无问题地从单个区域扩展到多个地理定位区域。
传递数据
代理服务是一个翻译代理。例如，当 webdav 客户端请求目录中的内容列表时，代理服务会将其转换为正确的快速调用。 swift 的响应被转换为适合 webdav 客户端的格式。
传递数据时，特别是文件，代理服务通过代理将内容传递到另一端。这意味着获取一个文件，即使是一个大文件，几乎是立即发生的。文件不存储在代理上，因此不需要大缓存。相反，它们只是根据需要通过更改格式。
在实践中
这个设置让我可以毫无问题地传输千兆字节范围内的大文件。我已经能够在 Mac、Linux、Windows、平板电脑甚至我的手机上使用它。
