这个HTTP头是错误的吗？

我想写一个torrent下载器，并且需要弄清楚如何联系跟踪器。我使用Fiddler2程序拦截从Vuze发送给它的跟踪器的跟踪器请求。这个HTTP头是错误的吗？

在发送的消息（如下所示）中，Connection标头声明了两次不同的值。

这是Connection头的正确用法吗？ Connection：keep-alive是做什么的？

GET /announce?info_hash=0Z%22...&azver=3&azas=12576 HTTP/1.1 
User-Agent: Azureus 4.7.0.2;Windows 7;Java 1.6.0_31 
Connection: close 
Accept-Encoding: gzip 
Host: tracker.update.vuze.com:6969 
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 
Connection: keep-alive

来源

2012-07-13 brnby

从RFC2616第4.2节：当且仅当该头字段整个字段值被定义为

多幅具有相同字段名的消息的报头字段可以是在消息本以逗号分隔的列表[即＃（值）]。它必须可以通过将每个后续字段值附加到第一个，每个分隔的一个 “字段名称：字段值”对，而不更改消息的语义，可以将多个标题字段组合到一个 “逗号。因此，接收到字段名相同的标题字段的顺序对于组合字段值的解释有意义，因此当转发消息时，代理不得更改这些字段值的顺序。

编辑：

据14.10节，连接是这样的字段名，所以具有多个连接头在技术上是正确。

从14.10开始，连接标题的语法生成是Connection = "Connection" ":" 1#(connection-token)，所以一个或多个逗号分隔标记是有效。

但实际上，可能会忽略第二个连接标头，因此一旦发送响应，Web服务器将期望关闭底层TCP连接。

对于HTTP 1.1，默认模式是让服务器为后续请求保持打开底层TCP连接，尽管许多服务器会限制在关闭连接之前发出的请求总数。

来源

2012-07-13 19:43:12

你错了，连接头像被定义为逗号分隔列表。 – 2013-11-18 01:30:50

谢谢。你是对的;我已经根据RFC中的语法生成澄清了我的答案。 – 2013-11-28 02:39:23

奇怪的是它有2个连接头字段。我认为你只能期望一个非确定性的行为，因为这种情况的处理完全取决于Web服务器的实现。它可能会结束与任何2（比方说）存储字段的散列映射。

基本上，保持活动意味着允许浏览器保持与服务器的连接并保持检索图像，脚本。通常情况并非如此。通常情况下，请求被给予响应后，与Web服务器的连接关闭。

来源

2012-07-13 19:36:08 Razvan

Connection: Close

表示请求完成后关闭连接。

Connection: keep-alive

表示保持连接为未来请求打开。

您应该只有一个连接参数。

因此，HTTP头是不正确的。

来源

2012-07-13 19:37:30

HTTP 1.1允许多个连接标头。多个这样的标题的语义被定义为与用逗号将所有值连接在一起的单个标题相同，例如，

Connection: close 
Connection: keep-alive

是一样的：

Connection: close,keep-alive

所以从技术上讲，这些头都很好。但是，我会预测，如果没有做一些实验，那里会有很多服务器（特别是没有经过很好测试的服务器，比如洪流跟踪器），他们会忽略这些头文件中的任何一个。

现在，更深层次的问题是“保持活力”是一些http 1.0扩展名，并且与“close”相矛盾，所以我猜这个组合只是torrent客户端中的一个bug。我想大多数追踪者不会允许永久连接，但是，我认为下注方式只能有一个“连接：关闭”标题。

来源

2013-11-18 01:35:22

这个HTTP头是错误的吗？

回答

相关问题