没有http标头的Http响应 [英] Http response with no http header

查看:154
本文介绍了没有http标头的Http响应的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经编写了一个迷你极简主义的http服务器原型(很大程度上受到了升级asio示例的启发),而且目前我还没有在服务器响应中放置任何http标头,只有html字符串内容。令人惊讶的是,它的工作正常。

I have written a mini-minimalist http server prototype ( heavily inspired by boost asio examples ), and for the moment I haven't put any http header in the server response, only the html string content. Surprisingly it works just fine.

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

In that question the OP wonders about necessary fields in the http response, and one of the comments states that they may not be really important from the server side.

我有暂时没有尝试回复二进制图像文件或gzip压缩文件,在这种情况下我认为必须有一个http标头。

I have not tried yet to respond binary image files, or gzip compressed file for the moment, in which cases I suppose it is mandatory to have a http header.

但仅限文本响应(html,css和xml输出),在我的服务器响应中包含http标头是否可以从不?可能存在哪些风险/错误?

But for text only responses (html, css, and xml outputs), would it be ok never to include the http header in my server responses ? What are the risks / errors possible ?

推荐答案

至少,必须提供标题状态行和日期。

At a minimum, you must provide a header with a status line and a date.

作为编写了许多协议解析器的人,我求你,在我的数字隐喻膝盖上,请哦,请哦,请不要完全忽略了规范只是因为你最喜欢的浏览器让你逃脱它。

As someone who has written many protocol parsers, I am begging you, on my digital metaphoric knees, please oh please oh please don't just totally ignore the specification just because your favorite browser lets you get away with it.

创建一个功能最少的程序是完全没问题的,只要它生成的数据是正确的。这不应该是一个主要负担,因为您只需要在响应的开头添加三行。其中一行是空白!请花几分钟时间写下两条光荣的代码,它会使您的回复数据符合规范。

It is perfectly fine to create a program that is minimally functional, as long as the data it produces is correct. This should not be a major burden, since all you have to do is add three lines to the start of your response. And one of those lines is blank! Please take a few minutes to write the two glorious line of code that will bring your response data into line with the spec.

标题为您真的应该供应:

The headers you really should supply are:


  • 状态行(必填)

  • 日期标题(必填)

  • 内容类型(强烈推荐)

  • 内容长度(强烈推荐),除非您使用的是分块编码

  • 如果你要返回HTTP / 1.1状态行,并且你没有提供有效的内容长度或使用分块编码,那么添加连接:关闭到你的标题

  • 将标题与正文分开的空行(必填)

  • the status line (required)
  • a date header (required)
  • content-type (highly recommended)
  • content-length (highly recommended), unless you're using chunked encoding
  • if you're returning HTTP/1.1 status lines, and you're not providing a valid content-length or using chunked encoding, then add Connection: close to your headers
  • the blank line to separate header from body (required)

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

You can choose not to send a content-type with the response, but you have to understand that the client might not know what to do with the data. The client has to guess what kind of data it is. A browser might decide to treat it as a downloaded file instead of displaying it. An automated process (someone's bash/curl script) might reasonably decide that the data isn't of the expected type so it should be thrown away.

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

From the HTTP/1.1 Specification section 3.1.1.5. Content-Type:


生成包含有效负载主体的消息的发件人应该是b
生成一个Content-Type头字段消息,除非
发件人不知道所包含的表示的
预期媒体类型。如果Content-Type头字段不存在,则收件人
可以假定媒体类型为application / octet-stream
([RFC2046],第4.5.1节)或检查数据到确定其类型。

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标头的Http响应的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆