我不能直截了当地说一件事。4.4.5 中的RFC 2616声明Message Length可以确定“ By the server closing the connection.”。

这意味着，服务器响应（例如返回大图像）响应Content-Length头中没有响应是有效的，但客户端应该继续获取直到连接关闭，然后假设所有数据都已下载。

但是客户端如何确定连接是由服务器故意关闭的呢？服务器应用程序可能在发送数据的过程中崩溃，服务器的操作系统很可能会发送FIN数据包以优雅地关闭与客户端的 TCP 连接。

Node.js 中内置的 HTTP 客户端似乎不支持流水线请求。但是，我想到可以创建一个在后台设置流水线的代理。以应有的方式获取响应数据可能会出现问题，但也许代理可以伪造一些套接字对象以使 HTTP 客户端正常工作？

这已经完成了吗？或者，是否有替代 HTTP 客户端可以替代支持流水线的主要客户端？（最终，我想将它与 AWS 开发工具包一起使用，因此它需要兼容。）

我知道可以Accept-Ranges: none在服务器上设置以建议客户端不要尝试范围请求。

我想知道是否有办法告诉浏览器不要尝试范围请求，而不必在服务器上进行任何更改。

例如，Chrome 或 Firefox 中是否有可以切换以阻止浏览器发出范围请求的设置？

我正在阅读rfc2616中的 http 标准。现在我想获得If-None-Match. 它给了我：

If-None-Match = "If-None-Match" ":" ("*" | 1#entity-tag )

是什么1#？或剂量1#entity-tag意味着确切的ETag？

根据RFC2616

Allow entity-header 字段列出了由 Request-URI 标识的资源所支持的方法集。该字段的目的是严格告知接收者与资源相关的有效方法。

它要求“405（不允许的方法）响应中必须存在允许标头字段。”

此外，它指出

该字段不能阻止客户端尝试其他方法。但是，应该遵循 Allow 头域值给出的指示。实际允许的方法集由源服务器在每次请求时定义。

因此，对于广泛使用的 REST API，在我看来，在响应其他相关 HTTP 方法（如 GET、PUT、POST、HEAD、PATCH（？））中设置 Allow 标头可能对希望发现功能的客户端有用/支持的资源操作。

但是，关于该主题的谷歌搜索并没有产生对我有帮助的结果。因此，寻找来自 SO 社区的意见。

TL; DR：正如主题所说 - 仅在处理响应标头之后才需要发送多部分帖子正文，在建立连接后收到。

根据 libcurl 文档，CURLOPT_HEADERFUNCTION 在收到标头数据后立即被 libcurl 调用。 但是经过简单的调查，这并没有发生。

如何重现：

回调：

简短的主要请求正文：

然后我们可以接收下一个日志（自 c++11 chrono epoch 以来的大量时间）：

输入 [0] 数据：[SSL 相关内容]

输入[0]数据：[完成等待100-继续]

ReadFromStateCallBack 1455532592078426519

...

ReadFromStateCallBack 1455532592507779449

HeaderCallback 1455532592937695923 [HTTP/1.1 100 继续]

HeaderCallback 1455532592937713786 [日期：2016 年 2 月 15 日星期一 10:36:32 GMT]

输入[0]数据：[服务器ATS未列入黑名单]

HeaderCallback：1455532593030759917 [HTTP/1.1 401 未授权]

来自标头的附加信息

正如您所见，libcurl 为自己的需要处理了 100-continue 标头，但仅在发送数据后才调用处理标头的回调。

此外，似乎收到了所有必要的标头。tcpdump 示例：

13:36:30.425361 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [S], seq 164841209, win 29200, options [mss 1460,sackOK,TS val 2164947 ecr 0,nop,wscale 7], 长度 0

13:36:30.639293 IP 74.112.184.85.https > 192.168.1.70.41895：标志 [S.]，seq 1336121630，ack 164841210，win 14480，选项 [mss 1460，sackOK，TS val 208393346752 秒，27393346752 秒]，长度为 0

13:36:30.639337 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [.], ack 1, win 229, options [nop,nop,TS val 2165000 ecr 2083933652], 长度 0

13:36:30.640031 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [P.], seq 1:297, ack 1, win 229, options [nop,nop,TS val 2165000 ecr 2083933652], 长度 296

13:36:30.853750 IP 74.112.184.85.https > 192.168.1.70.41895：标志 [.]，ack 297，win 122，选项 [nop,nop,TS val 2083933866 ecr 2165000]，长度 0

13:36:30.861507 IP 74.112.184.85.https > 192.168.1.70.41895：标志 [P.]，seq 1:2690，ack 297，win 122，选项 [nop,nop,TS val 2083933874 ecr 2165000]，长度 2689

^^^^^ - 就在这里。

13:36:30.861524 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [.], ack 2690, win 271, 选项 [nop,nop,TS val 2165056 ecr 2083933874], 长度 0

13:36:30.862654 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [P.], seq 297:423, ack 2690, win 271, options [nop,nop,TS val 2165056 ecr 2083933874], 长度 126

13:36:31.076949 IP 74.112.184.85.https > 192.168.1.70.41895：标志 [P.]，seq 2690:2741，ack 423，win 122，选项 [nop,nop,TS val 2083934090 ecr 2165056]，长度 51

13:36:31.077286 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [P.], seq 423:693, ack 2741, win 271, options [nop,nop,TS val 2165110 ecr 2083934090], 长度 270

13:36:31.330808 IP 74.112.184.85.https > 192.168.1.70.41895: 标志 [.], ack 693, win 130, 选项 [nop,nop,TS val 2083934344 ecr 2165110], 长度 0

13:36:32.078397 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [P.], seq 693:870, ack 2741, win 271, options [nop,nop,TS val 2165360 ecr 2083934344], 长度 17

13:36:32.078533 IP 192.168.1.70.41895 > 74.112.184.85.https: 标志 [.], seq 870:2218, ack 2741, win 271, options [nop,nop,TS val 2165360 ecr 2083934344], 长度 1348

重复发送数据

由于 SSL 连接，我无法使用 -A 查看 tcpdump，以确保在建议的部分中收到标头。

软件：

• libcurl(7.36)
• 编译器 GCC(4.8.4)

PS对我来说，似乎libcurl对[RFC 2616(8.2.4)]有错误的行为( https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html )

PPS 如果存在则相同的行为连接：关闭标头。

我已经看到了这个 SO 问题的答案：Trusting "Content-Type" on File Uploads

它们在直觉上是有意义的。

但是，根据 RFC 2616 Sec 7.2.1，

“当且仅当媒体类型不是由 Content-Type 字段给出时，接收者可以尝试通过检查其内容和/或用于识别资源的 URI 的名称扩展名来猜测媒体类型。 "

我想知道将 RFC 这部分应用于服务器时背后的原因 - 为什么服务器应该信任客户端的标头并且仅在缺少内容检查时才回退？效率是我能想到的原因之一。或者我可能误解了 RFC？

我正在尝试使用 Play向客户端发送303 See Other带有Location标头和响应正文的详细信息，详细说明它们被重定向的原因（这似乎允许每 RFC 26162.3.10 ） ：

但是当我包含位置标头时，响应正文返回空。省略标题会导致正确返回正文，但当然我也需要标题。

此外，它似乎是关于Location标题的特定内容。设置其他标题不会导致正文被省略。

发回Location标头和响应正文的最佳方式是什么？

我正在使用ETag标头进行缓存，浏览器发送相应的If-None-Match标头。最初，我只是比较了这些标头并且它起作用了。

后来我想到rfc2616允许实体列表，所以我修复了它。问题是，如果修复被使用...

• 浏览器是否曾经发出带有If-None-Match包含多个实体的标头的请求？
• 还有其他现实世界的用途吗？

例子：

• 我们提供一个 URL http://.../foo/download.csv
• 网络客户端（MS office）打开上面的 URL 并尝试使用 http OPTIONS 请求访问（出于我真的不知道的原因）http://.../foo/ 。
• 到目前为止，或应用程序返回 404，因为上述 URL 不存在（即使对于 GET 请求）。

我认为所有 OPTIONS 请求都应该得到 405。URL 是否可以通过 GET 或 POST 访问并不重要。

这是否符合 http 规范？

这是我为什么认为 405 更适合的解释：如果有 OPTIONS 请求，我不想查看路径。我不在乎路径是什么样子，应该总是有相同的答案：不允许。

到目前为止，这取决于：如果注册了 GET-view，则返回 405。否则返回 404。

更新：404 与 405

不允许使用 HTTP-Spec 405 方法

Request-URI 所标识的资源不允许使用 Request-Line 中指定的方法。响应必须包含一个 Allow 标头，其中包含所请求资源的有效方法列表。

来源：https ://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6