http-serve

Rust 用于通过 hyper 0.14.x 和 tokio 服务器端编程响应 HTTP GET 和 HEAD 的辅助工具。

此 crate 提供两种响应 HTTP GET 和 HEAD 请求的方法

• serve 函数可用于服务一个 Entity，这是一个表示可重用、可字节范围 HTTP 实体的 trait。《code>Entity 必须在每次调用时产生相同的数据，事先知道其大小，并能按需生成数据的一部分。
• streaming_body 函数可用于向一个完整响应添加正文。如果需要正文（在 GET 而不是 HEAD 请求中），则返回一个 BodyWriter（实现了 std::io::Writer）。调用者应生成完整的正文或调用 BodyWriter::abort，导致 HTTP 流突然终止。

它提供静态文件 Entity 实现，以及一个（目前仅限 Unix）从本地文件系统服务完整目录树的辅助工具，包括在客户端声明接受 Accept-Encoding: gzip 时自动查找以 .gz 结尾的文件。

为什么有两种方法？

它们各有优缺点。下表显示了其中的一些

[1]: streaming_body总是发送完整的正文。由于接口限制，使用字节范围服务没有太大意义。应用程序每次都会生成所有字节，并且http-serve的缓冲逻辑必须很复杂才能很好地处理多个范围。

[2]: streaming_body通常在持有锁或打开数据库事务时附加，此时不希望有回压。可以添加对“等待点”的支持，其中调用者明确希望回压。这使得它更适合大型流，甚至无限流，如Server-sent events。

[3]: streaming_body尚不支持生成etags或遵守条件GET请求。欢迎提交PR！

[4]: serve不会自动应用Content-Encoding: gzip，因为内容编码是您提供的实体的属性。实体的etag、长度和字节范围边界必须与编码匹配。您可以使用http_serve::should_gzip辅助函数来决定提供普通实体或gzip实体。当浏览器通过TE: gzip请求时，serve可以自动应用相关的Transfer-Encoding: gzip，但常见浏览器已选择避免请求或处理Transfer-Encoding。

更多信息请参阅文档。

还有一个内置的Entity实现，ChunkedReadFile。它从本地文件系统提供静态文件，在单独的线程池中读取块以避免阻塞tokio反应器线程。

尽管如此，您不仅限于内置的实体类型。您可以提供自己的实体，以满足您的任何需求

• 通过include_bytes!嵌入到二进制文件中的字节。
• 从另一个HTTP服务器或网络文件系统中检索的字节。
• 基于memcached的另一个实体的缓存。
• 对于计算etag、大小和字节范围比计算整个数据更便宜的其他任何内容。 （参见moonfire-nvr生成代表任意时间范围的.mp4文件的逻辑。）

http_serve::serve类似于golang的http.ServeContent。它是从moonfire-nvr的.mp4文件提供中提取出来的。

示例

• 提供单个文件

  $ cargo run --example serve_file /usr/share/dict/words
  

• 提供目录树

  $ cargo run --features dir --example serve_dir .
  

作者

有关详细信息，请参阅AUTHORS文件。

许可证

您可以选择MIT或Apache；请参阅LICENSE-MIT.txt或LICENSE-APACHE。