Question

我一直在涉及底层的客户端 - 服务器通信（cURL，浏览器和服务器响应，以及其他各种）。我想在这一点上我理解了请求和响应的基本结构：

请求：

(Method) (File) (Protocol)
(Headers)
(Empty)
(Body?)

响应：

(Protocol) (Code) (Meaning)
(Headers)
(Empty)
(Body?)

这一点工作正常，直到我发送了压缩信息。更准确地说，我使用gzip在响应中发送HTML。

首先，我正在使用Chrome的更新版本进行测试 - 如果我使用预构建的HTTP服务器解决方案，gzip（完全按照我现在使用的方式）可以正常工作。

在Chrome发送的“Accept-Encoding”标题中，它声明它将接受gzip。我的猜测是有一些特定的东西我还没有遇到（并且无法通过搜索找到）。

所有这一切，这是回复：

HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 205

(Zipped data...)

如果我删除gzip并将其他所有内容完全相同，这样可以正常工作。 Content-Length是压缩数据的长度，而不是原始数据，但我评论说要确保它没有做我没想到的事情。 Chrome并不要求“内容长度”来确定它想要做什么。

在某个阶段，我还有Content-Type: text/html; charset=utf-8没有任何区别（在zip下面，字符串在服务器上转换为utf-8）。

最初我将标题和压缩到主体以保持一致性（最低长度）。我认为它失败了，因为浏览器必须能够看到标题，以确定是否会压缩正文。

但是，在这两种情况下，Chrome都会显示“ERR_CONTENT_DECODING_FAILED”，这是经典的“我们不知道如何解码信息。”

在尝试将其嵌入相同的响应之前，我首先发送了标题，然后是第二个，认为这可能是最好的方法 - 两种不同的响应。

Chrome认为这意味着服务器正在推送可下载内容并进入无限接受循环，所以显然这不是解决方案。此外，它没有使用收到的内容。

从技术上讲，普通的Web服务器会在发送第二个响应后结束传输，但我正在尝试不用它来更好地理解连接。

我有什么遗漏，或者对可能出现的问题有什么想法？

谢谢！

修改的

代码分散在各种功能中（我怀疑有人想看~300行），但我挑选了相关的部分。就在gzip之前，self.written是html。

const zipper = require('zlib');
push(value, callback)
{
  this.socket.write(value, callback);
}

let self = this;
zipper.gzip(self.written, function(error, zipped)
{
  self.setHeaders(
  {
    'Content-Encoding': 'gzip',
    'Content-Length': zipped.length
  });

  self.getHeaderString(function(error, headers)
  {
    self.push(headers + zipped, callback);
  });
});

当我在console.log中做出最终回复：

zip响应结构压缩

0 个答案: