5

我已经编写了一个极简的 http 服务器原型（深受 boost asio 示例的启发），目前我还没有在服务器响应中放置任何 http 标头，只有 html 字符串内容。令人惊讶的是，它工作得很好。

在那个问题中，OP 想知道 http 响应中的必要字段，其中一条评论指出，它们在服务器端可能并不重要。

目前我还没有尝试响应二进制图像文件或 gzip 压缩文件，在这种情况下，我认为必须有一个 http 标头。

但是对于纯文本响应（html、css 和 xml 输出），永远不要在我的服务器响应中包含 http 标头可以吗？可能的风险/错误是什么？

4

1 回答 1

10

至少，您必须提供带有状态行和日期的标题。

作为编写了许多协议解析器的人，我恳求您，以我的数字隐喻膝盖，请哦，请哦，请不要仅仅因为您最喜欢的浏览器让您侥幸逃脱就完全忽略规范。

创建一个功能最少的程序是完全可以的，只要它产生的数据是正确的。这不应该是一个主要的负担，因为您所要做的就是在响应的开头添加三行。其中一行是空白的！请花几分钟时间编写两行代码，使您的响应数据符合规范。

您真正应该提供的标题是：

  • 状态行（必填）
  • 日期标题（必需）
  • 内容类型（强烈推荐）
  • 内容长度（强烈推荐），除非您使用分块编码
  • 如果您返回 HTTP/1.1 状态行，并且您没有提供有效的内容长度或使用分块编码，则添加Connection: close到您的标头
  • 将标题与正文分开的空白行（必需）

您可以选择不随响应发送内容类型，但您必须了解客户端可能不知道如何处理数据。客户端必须猜测它是什么类型的数据。浏览器可能决定将其视为下载文件而不是显示它。自动化过程（某人的 bash/curl 脚本）可能会合理地确定数据不是预期的类型，因此应该将其丢弃。

来自HTTP/1.1 规范第 3.1.1.5 节。内容类型：

生成包含有效负载正文的消息的发送者应该在该消息中生成 Content-Type 头字段，除非发送者不知道封闭表示的预期媒体类型。如果 Content-Type 头字段不存在，接收者可以假设媒体类型为“application/octet-stream”（[RFC2046]，第 4.5.1 节）或检查数据以确定其类型。

于 2012-11-21T03:54:31.687 回答