问题标签 [rfc2616]

我无法从RFC 2616判断 HTTP 客户端是否应该接受包含 Content-Length: 0 或 Transfer-Encoding: 分块标头的 204 No Content 响应。这些标头似乎破坏了一些 HTTP 客户端和代理，它们显然试图读取空的响应正文，但规范显示：

1. 任何“不得”包含消息体的响应消息（例如 1xx、204 和 304 响应以及对 HEAD 请求的任何响应）始终以标头字段之后的第一个空行终止，无论实体如何-消息中存在的标头字段。

对我来说，“无论实体标题字段如何”都意味着客户应该容忍这种情况。Erlang HTTP 库选择了这种解释。然而，lighthttpd和IBM选择了相反的解释——服务器不应该包含这些响应头，因为这些响应被禁止有正文。

那么 Web 应用程序是否应该从响应中删除这些标头，或者网络基础设施和客户端是否应该容忍 204 No Content、304 Not Modified 等的标头？

如果在 Content-Type 标头中未指定字符集参数，则RFC2616 第 3.7.1 节似乎暗示 ISO8859-1 应假定用于子类型“text”的媒体类型：

当发送者没有提供明确的字符集参数时，“文本”类型的媒体子类型被定义为在通过 HTTP 接收时具有“ISO-8859-1”的默认字符集值。

除“ISO-8859-1”或其子集以外的字符集中的数据必须用适当的字符集值标记。

但是，我经常看到应用程序提供带有 Content-Type 值的 Javascript 文件，例如“application/x-javascript”（即没有字符集参数），即使这些脚本包含非 ASCII UTF-8 字符，如果解释这些字符会损坏为 ISO8859-1。

这似乎不会给客户带来问题。客户端如何知道将字节解释为 UTF-8？是否有其他字符数据子类型的规则暗示 UTF-8 应该是默认值？这是在哪里记录的？

WinHttpReadData的文档说，关于HTTP 的分块传输编码：

从 Windows Vista 和 Windows Server 2008 开始，WinHttp 使应用程序能够对发送到服务器的数据执行分块传输编码。当 WinHttp 响应中存在 Transfer-Encoding 标头时，WinHttpReadData 在将数据提供给应用程序之前会剥离分块信息。

谁能破译这个？

Q1首先，此文本在 WinHttpReadData 页面上，用于...读取HTTP 客户端应用程序中的数据，特别是响应数据。所以当它说是什么意思

从 Windows Vista 和 Windows Server 2008 开始，WinHttp 使应用程序能够对发送到服务器的数据执行分块传输编码。

WinHttpReadData 函数不与发送到服务器的数据一起使用。从服务器读取数据时使用它。

查阅WinHttpWriteData函数的文档，该函数用于将数据作为 HTTP 请求的一部分发送到服务器，没有提到分块传输功能。

Q2假设我知道新的分块传输支持是多少，我如何获得这种支持？ 它说它是 Vista 和 WS2008 上的新功能。如果我编写一个在 WS2003 上运行并使用 WinHttpReadData 的应用程序遇到分块响应或 WinHttpWriteData，并且它想要发送分块请求，会发生什么情况？

字里行间，这个文档是否说我需要链接到 Vista 时代的 Windows SDK 或更高版本中的 WinHttp.lib 才能获得进行分块编码的能力？或者在 WS2003 上真的不可能吗？换句话说，使用这个库进行分块传输的应用程序必须在指定的操作系统上运行？

这可能读起来像咆哮，但事实并非如此。我真的很想知道。

对我来说，HTTP 1.1 RFC 和各种实现的最弱点之一是如何处理 100 Continue 标头。

我在网上搜索了一段时间，并查看了不同的实现。但是，有一件事我不确定。100 Continue 消息的正确语法是什么？一些消息来源声称，这必须是没有任何进一步标题行的单个响应行。但是，我在 RFC 2616 中找不到这一点。那么什么是对的呢？

或者

?

我直接从数据包中解析 HTTP 数据（无论 TCP 是否重建，你都可以假设它是）。

我正在寻找尽可能准确地解析 HTTP 的最佳方法。

这里的主要问题是 HTTP 标头。

查看HTTP/1.1 的基本 RFC，似乎 HTTP 标头解析会很复杂。RFC 为标头的不同部分描述了非常复杂的正则表达式。

我应该编写这些正则表达式来解析 HTTP 标头的不同部分吗？

到目前为止，我为 HTTP 标头编写的基本解析是针对通用 HTTP 标头的：

并且我已经包括用逗号分隔值替换内部LWS和SP重复标题，field-name如第 4.2 节所述。

但是，例如查看第 14.9 节会表明，为了解析 I 的不同部分，field-value我需要一个更复杂的解析方案。

field-value假设我想为解析器用户提供 HTTP 的全部功能并解析 HTTP 的每个部分，您如何建议我应该处理 HTTP 解析的复杂部分（特别是）？

对此的设计建议也将不胜感激。

谢谢。

这个问题是关于 HTTP 标头“Accept-Encoding”的媒体类型的优先顺序，当所有的权重相同时，我的博客上的这条评论已经提示了这个问题。

背景：

Accept-Encoding 标头采用逗号分隔的浏览器可以接受的媒体类型列表，例如 gzip、deflate

还可以指定质量因子以优先考虑其他媒体类型，例如在“gzip;q=.8,deflate”的情况下，首选 deflate - 但与此问题无关。注意：带有“q=0”的类型表示“不可接受”。

RFC2616还指出应该首先对媒体类型定义的“最具体的参考”进行加权。即“text/html;level=1”应该用在“text/html”之上——这也与问题无关。

问题：

在以下情况下，哪种媒体类型具有优先权？

两种类型都具有等效的品质因数 1，并且两种类型对浏览器都是“可接受的”——因此可以使用任何一种。我一直认为输入的第一种类型应该是“首选”，但在RFC中似乎没有针对这种特殊情况的具体示例或偏好。

我必须在 Java 中实现一个 HTTP 客户端，并且根据我的需要，最有效的方法似乎是实现 HTTP 管道（根据RFC2616）。

顺便说一句，我想管道 POST。（另外，我不是在谈论多路复用。我在谈论流水线，即在接收任何响应批处理 HTTP 请求之前通过一个连接进行许多请求）

我找不到明确声明它支持流水线的第三方库。但是我可以使用例如Apache HTTPCore来构建这样的客户端，或者如果我必须自己构建它。

我的问题是这是否是个好主意。我没有找到任何权威参考资料表明 HTTP 流水线不仅仅是一种理论模型，而是由 HTTP 服务器正确实现的。此外，所有支持流水线的浏览器都默认关闭此功能。

所以，我应该尝试实现这样的客户端，否则我会因为服务器的实现（或代理）而遇到很多麻烦。是否有任何参考可以提供这些指导？

如果这是一个坏主意，那么提高效率的替代编程模型是什么？单独的 TCP 连接？

HTTP 服务器是否有任何理由有时会响应Vary: *，有时会响应Vary: Foo对同一资源的请求？

缓存应该做什么，如果在接收（和缓存）两个响应之后，它会收到一个带有匹配Foo标头的请求，该Vary: Foo响应适合该响应？它可以提供匹配的响应，还是单独的Vary: *响应覆盖它？

如果服务器返回，http 客户端应该怎么做Cache-Control: private, public？

我有一种感觉private应该覆盖public，但我在 RFC 中找不到确认（除了MUSTinprivate和MAYin public）。

求救求救求救！！！我在 java 中创建了一个原始 HttpServer，它侦听端口 80 并使用 Get 方法打开文件等（127.0.0.1/index.html）。我想从 HTTP/1.1 (RFC 2616) 协议创建请求标头（接受、接受语言、用户代理）和响应标头（内容长度和缓存控制）。你能帮我怎么做吗...你会救我的命！！！！！！！！！谢谢！