http-conduit:使用gzip传输数据

时间:2014-02-15 04:26:28

标签: haskell gzip content-encoding http-conduit

我打算使用http-conduit通过HTTP / HTTPS获取大量数据。为了有效地执行此操作,我想使用Accept-Encoding: deflate,gzip标头允许服务器(如果支持)以压缩方式传输数据。

但是,我想要获取的某些服务器似乎错误地使用Content-Encoding: gzip标头响应而未返回gzip数据。

因此我需要处理这些案件:

  • 服务器不支持压缩 - >返回简单回复正文
  • 服务器返回gzipped / deflated内容 - >返回解压缩的响应主体
  • 服务器说(在响应头中它返回gzip压缩内容,但gzip解码失败 - >返回普通响应正文

在第三种情况下,它可以(在这种特定情况下)安全地假设,明文,未压缩数据看起来不像gzip数据,所以响应标题说它是gzip&& un-gzip失败完全等同于数据未压缩

如何使用http-conduit

执行此操作

注意:这个问题故意不会显示研究工作,因为它已经以Q& A风格的方式立即得到了解答。

1 个答案:

答案 0 :(得分:0)

为了使这个答案更简洁,我们将使用代码和&我以前的一些帖子中的概念:

    来自here
  • simpleHttpWithManager
  • here
  • 的宽容gzip / deflate解码

为避免冗余,我将首先解释基本步骤,然后提供完整的示例。

首先,我们将处理发送标题。请注意,wile http-types包含hContentEncodinghAcceptEncoding未预定义。除此之外,这是一项微不足道的任务。

发送请求后,我们需要检查是否有Content-Encoding。如果没有,我们将假设未压缩的明文,否则我们需要检查它是gzip还是deflate。在这种情况下,哪一个确切无关紧要,因为[zlib]支持按标题自动检测。

对于这个相当简单的示例,我们假设如果服务器返回既不存在也不存在Content-Encoding也不gzip的{​​{1}}值,则不会压缩响应。由于我们不允许(通过deflate)其他压缩,例如Accept-Encoding,服务器会以这种方式违反HTTP标准。

如果我们检测到压缩编码,我们会尝试解压缩并返回它。如果失败或数据根本没有压缩,我们将返回普通的响应体。

以下是示例:

sdch