我已经编写了一个极简主义的 http 服务器原型(prototype)(深受 boost asio 示例的启发)，目前我还没有在服务器响应中放置任何 http header ，只有 html 字符串内容。令人惊讶的是它工作得很好。
In that question OP 想知道 http 响应中的必要字段，其中一条评论指出它们在服务器端可能并不重要。
目前我还没有尝试响应二进制图像文件或 gzip 压缩文件，在这种情况下我认为必须有一个 http header 。
但对于纯文本响应(html、css 和 xml 输出)，是否可以从不在我的服务器响应中包含 http header ？可能存在哪些风险/错误？
最佳答案
至少，您必须提供带有状态行和日期的标题。
作为一个写过很多协议(protocol)解析器的人，我求求你，在我的数字隐喻膝盖上，拜托哦拜托哦拜托不要仅仅因为你最喜欢的浏览器让你摆脱它。
创建一个功能最少的程序是完全可以的，只要它产生的数据是正确的。这应该不是一个主要负担，因为您所要做的就是在响应的开头添加三行。其中一行是空白!请花几分钟时间编写两行出色的代码，这将使您的响应数据符合规范。
您真正应该提供的 header 是:
- 状态行(必需)
- 日期标题(必需)
- 内容类型(强烈推荐)
- content-length(强烈推荐)，除非你使用分块编码
- 如果您要返回 HTTP/1.1 状态行，并且您没有提供有效的内容长度或使用分块编码，则将
Connection: close添加到您的 header - 分隔标题和正文的空行(必需)
您可以选择不在响应中发送内容类型，但您必须了解客户端可能不知道如何处理数据。客户端必须猜测它是什么类型的数据。浏览器可能决定将其视为下载文件而不是显示它。自动化流程(某人的 bash/curl 脚本)可能会合理地确定数据不是预期类型，因此应该将其丢弃。
来自HTTP/1.1 Specification第 3.1.1.5 节。内容类型:
A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.
关于没有 http header 的 Http 响应，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13483781/