问题标签 [rfc2616]

我无法理解 204 HTTP 状态码的用例。RFC2616 说：

10.2.5 204 无内容

服务器已完成请求，但不需要返回实体主体，并且可能希望返回更新的元信息。响应可能包括实体头形式的
新的或更新的元
信息，如果存在，应该与
请求的变体相关联。

如果客户端是用户代理，它不应该改变导致请求被发送的文档视图。这个响应主要是为了允许输入动作发生而不导致用户代理的活动文档视图发生变化，尽管任何新的或更新的元信息应该应用于当前在用户代理的活动视图中的文档。

204 响应不能包含消息体，因此总是由头字段之后的第一个空行终止。

“文档视图”是指 DOM 吗？

例如，如果我触发 AJAX 请求删除用户，并在我的请求成功完成后更新我的页面以从列表中删除用户，服务器应该给我一个带有 {} 作为响应的 200 还是不带 {} 的 204身体 ？

编辑：我主要关心的是“如果客户端是用户代理，它不应该改变导致发送请求的文档视图”。部分。用我自己的话重新表述：如果我返回 204，我可以更新 DOM 吗？

在响应头中指定缓存行为的一种相当标准的方法是同时设置一个Date值和一个Expires值。（以及某种缓存控制指令，例如cache-control=public）。

假设在 time now发出请求，假设now是：

Tue, 24 Jun 2014 13:36:05 GMT

然后，将缓存值设置为 1 小时的标准响应可能包含以下标头：

Date: Tue, 24 Jun 2014 13:36:05 GMT
Expires: Tue, 24 Jun 2014 14:36:05 GMT

这将（并且应该）告诉任何中间缓存或 PoP 从现在起将资源缓存 1 小时。

但是，如果Expires值和值都在Date过去怎么办。（也许，比如说，因为错误的服务器时钟）。

如果我们考虑同时提出另一个请求，现在是：

Tue, 24 Jun 2014 13:36:05 GMT

如果相应的响应包含以下标头值怎么办：

Date: Tue, 24 Jun 2014 11:10:00 GMT
Expires: Tue, 24 Jun 2014 11:44:00 GMT

在这里，这两个值都已经过去了。过去的Expires值通常足以触发 a no-cache，但是Date过去的值的影响是什么。

缓存实现是否应该使用 的值Date来计算偏移量Expires，然后使用它来创建now + offset的到期值？

RFC2616 日期部分
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
过去没有提到日期值

RFC2616 Expires 部分
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
规定如果Date === Expires，则响应“已经过期”。

这些似乎都没有提到两者都已经过去的Date情况Expires？

更新 / RFC2616 已死
进一步阅读表明RFC2616 已死，并已被一组更具体的 RFC 取代。

新的RFC7234 - HTTP/1.1：缓存包含计算新鲜度生命周期，其中包含以下语句：

如果存在 Expires 响应头字段，则使用其值减去 Date 响应头字段的值

这似乎准确地指定了上面概述的内容 - 使用 expires 值：

expiry=(Expires - Date) + Now

原始 RFC 中似乎没有任何等效声明。对于那些仍然遵循 RFC2616 的人，行为是否取决于各个浏览器/缓存供应商？

我对 Content-Encoding 和 Transfer-Encoding 的使用有疑问：

请让我知道我的以下理解是否正确：

客户端在其请求中可以使用 accept-encoding 标头指定它愿意接受的编码类型。因此，如果服务器希望在传输之前对消息进行编码，例如。gzip，它可以压缩实体（内容）并添加 content-encoding: gzip 并通过 HTTP 响应发送。在接收时，客户端可以接收并解压缩和解析实体。

在传输编码的情况下，客户端可以指定它愿意接受的编码类型并即时执行其操作。即如果客户端发送一个TE：gzip；q=1，这意味着如果服务器愿意，它可以使用 Transfer-Encoding: gzip 发送 200 OK 并且当它尝试发送流时，它可以压缩并发送，客户端在接收到内容后，可以即时解压缩和执行其解析。

我的理解在这里吗？请评论。

另外，动态压缩实体与先压缩实体然后传输它的基本优势是什么？传输编码是否仅对分块响应有效，因为我们在传输之前不知道实体的大小？

我有一个问题，当 HEAD 发送到资源并且服务器决定执行分块编码时，HTTP 服务器响应如何？

如果服务器总是希望对特定资源的 GET 执行分块编码，因为它在生成响应时不知道确切的内容长度，那么当在同一资源上发送 HEAD 时服务器应该如何表现。

浏览器是否缓存请求重定向的目标位置？例如。

从我的测试中，我得出结论，没有但想确定。

我对 HTTP 连接关闭有两个问题：

1. 如果客户端使用 Connection: close to HTTP Server 发送 HTTP 请求，客户端收到响应后发送 TCP FIN 是 HTTP Server 还是客户端的责任？

2. 如果客户端发送格式错误的 HTTP 请求，而服务器发送 400 BAD REQUEST，则最好由服务器关闭连接（即使 HTTP 请求具有连接：保持活动）还是保持连接的好习惯还活跃吗？

提前感谢您回答我的问题？

如何在我的 Android 应用程序中获取 RFC 2616 格式的当前日期？

例如：格林威治标准时间 2006 年 4 月 5 日星期三 21:12:00

我正在尝试在我的服务器中实现 HTTP，但无法找到有关如何处理多个预告片标头字段（使用分块编码）的任何信息。

标准 ( https://www.rfc-editor.org/rfc/rfc2616#section-14.40 ) 指出：“Trailer 通用字段值表示给定的标头字段集存在于使用分块编码的消息的尾部中传输编码。”

但没有说明如何在此标头中指定多个标Trailer头。

例如，如果请求或响应有两个尾部标头，Example1并且Example2，您将如何构造Trailer标头？

像这样：Trailer: Example1 Example2或者Trailer: Example1,Example2或者什么？

I would like to use CouchDB for keeping some logs (don't ask why ;-)) and I would like to make use of CouchDB's attachment feature. It should be noted that I have a lot of logs, but each log is rather small, I don't expect any of them to exceed 1Mb (usually they are more in the couple of Kb range).

AFAICS I have a couple of options:

1. I could accumulate the logs on server side and push the whole logs in one go to the server as an attachment, but it would mean that they wouldn't be available right away :-(
2. I could push the logs in regular intervals, but for updating them I would need to download them again attach more info to them and push them back to CouchDB

I'm not so happy with neither of those solutions, even though that would be possible which brings me to a possible third option (and my question).

For the GET request CouchDB clearly supports the (Content-)Range header (doesn't seem to be the standard one according to RFC 2616). RFC 2616 also does not limit the Content-Range to only GET requests (this opinion seems to be shared with others).

So the question is whether CouchDB supports this also for the PUT request. In this case I could attach to the attachment which would be ideal for my use case :-)

我正在解析 HTTP 标头。我想将标头值拆分为有意义的数组。

例如，Cache-Control: no-cache, no-store应该返回['no-cache','no-store'].

HTTP RFC2616 说：

当且仅当该头字段的整个字段值被定义为逗号分隔列表[即，#(values)] 时，具有相同字段名称的多个消息头字段可能出现在消息中。必须可以将多个头字段组合成一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。因此，接收具有相同字段名称的头字段的顺序对组合字段值的解释很重要，因此代理在转发消息时不得更改这些字段值的顺序

但我不确定反过来是否正确——用逗号分割是否安全？

我已经找到了一个导致问题的例子。例如，我的用户代理字符串是

即，它在“KHTML”之后包含一个逗号。显然我没有多个用户代理，因此拆分此标头没有意义。

User-Agent 字符串是唯一的例外，还是还有更多？