带有 HEAD 请求的 Content-Length 标头？答案

【问题标题】：Content-Length header with HEAD requests?带有 HEAD 请求的 Content-Length 标头？
【发布时间】：2011-04-20 18:28:22
【问题描述】：

http spec 表示HEAD 请求：

HEAD 方法与 GET 相同，只是服务器不得在响应中返回消息体。响应 HEAD 请求的 HTTP 标头中包含的元信息应该与响应 GET 请求时发送的信息相同。

对HEAD 请求的响应是否应该包含Content-Length 标头？即使没有响应正文，它是否应该是 GET 请求中返回的值？还是应该 Content-Length 为 0？

【问题讨论】：

标签： http rest http-headers

【解决方案1】：

在我看来，HTTP 1.1 RFC 非常具体：

内容长度 entity-header 字段表示实体的大小，十进制发送给接收者的 OCTET 数量，或者，在 HEAD 的情况下方法，将发送的实体主体的大小有请求是 GET。

【讨论】：

有趣的是，curl 告诉你 body 丢失了......他们在阅读回复时可能不“知道”该方法是 HEAD 并假设 body 丢失了。
curl --head 的表现优于 curl -X HEAD。
听不懂它说什么，你能说得简单点吗？
@deadManN in HEAD 请求 Content-Length 应该与 GET 请求中的相同，即使没有实际的正文。

【解决方案2】：

Section 14.13 of the HTTP/1.1 规范详细说明了 Content-Length 标头，并表示：

应用程序应该使用这个字段来表示的传输长度消息体，除非这是节中的规则禁止的 4.4.

“应该”这个词有一个very specific meaning in RFCs：

应该这个词，或形容词“推荐”，表示在特定情况下可能存在忽略特定项目的正当理由，但在选择不同的课程之前必须理解并仔细权衡全部含义。

因此，您可能并不总是看到 Content-Length。通常，对于任何动态生成的内容，您可能看不到它，因为这对于为探索性 HEAD 请求提供服务可能过于昂贵。例如，对 Apache 的静态文件的 HEAD 请求将具有 Content-Length，但对 PHP 脚本的请求可能没有。

例如，试试这个网站...

telnet stackoverflow.com 80

HEAD / HTTP/1.0
Host:stackoverflow.com

HTTP/1.1 200 OK
Date: Mon, 11 Jan 2016 10:58:25 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Set-Cookie: __cfduid=c2eb4742a1e02d89cab0402220736c0bd1452509905; expires=Tue, 10-Jan-17 10:58:25 GMT; path=/; domain=.stackoverflow.com; HttpOnly
Cache-Control: public, no-cache="Set-Cookie", max-age=36
Expires: Mon, 11 Jan 2016 10:59:02 GMT
Last-Modified: Mon, 11 Jan 2016 10:58:02 GMT
Vary: *
X-Frame-Options: SAMEORIGIN
X-Request-Guid: 487e80bc-3783-4cfd-d883-a3bc84253234
Set-Cookie: prov=8dc24306-c067-45eb-bf5d-cffa855c2b03; domain=.stackoverflow.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
Server: cloudflare-nginx
CF-RAY: 26303c15f8e035a2-LHR

那里没有内容长度。

【讨论】：

值得注意的是，如果是 Transfer-Encoding: chunked 响应，您也不会看到 Content-Length。
@PaulDixon 你能解释一下这个线程吗？谢谢。 stackoverflow.com/questions/34290203/…
对 google.com 的 HEAD 请求现在（2016 年 1 月 11 日）也将返回 Content-Length。
嗯，这个例子运行了 6 年！已将其更改为使用 stackoverflow.com :)
我认为这个例子也不再适用了；对 stackoverflow.com 的 HEAD 请求现在返回 Content-Length。

【解决方案3】：

是的，HEAD 响应的Content-Length应该，但并非总是（参见@Paul's answer）包含GET 响应的Content-Length 值：

堆栈溢出：

> telnet stackoverflow.com 80
HEAD / HTTP/1.1
Host: stackoverflow.com


HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Length: 362245                           <--------
Content-Type: text/html; charset=utf-8
Expires: Mon, 04 Oct 2010 11:51:49 GMT
Last-Modified: Mon, 04 Oct 2010 11:50:49 GMT
Vary: *
Date: Mon, 04 Oct 2010 11:50:49 GMT

谷歌没有：

> telnet www.google.com 80
HEAD / HTTP/1.1
Host: www.google.ie


HTTP/1.1 200 OK
Date: Mon, 04 Oct 2010 11:55:36 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked

【讨论】：

我认为您看到的是由于未使用 HTTP/1.0 而收到的错误消息的内容长度。如果您发送正确的 1.0 HEAD 请求，则不会获得内容长度。我也在本地 apache 实例上尝试过，同样没有返回内容长度。
@Paul：修复了我的格式错误的请求。但是，我仍然应该得到Content-Length。即使使用HTTP/1.0：i.imgur.com/iq9bm.jpg
是的，StackOverflow IIS 服务器确实会发送它。谷歌没有。
@Paul：很有趣。不过，谷歌不会发送 200 条回复。我得到了所有其他返回码：301、302、400 等。+1 用于找到“应该”的正确定义:)
如何在nginx中添加header？

【解决方案4】：

HTTP-spec at W3C 声明：

如果新的字段值表明缓存的实体与当前实体不同（如 Content-Length 的变化所表明的那样，...

这（对我而言）意味着它应该像在 GET 响应中一样保持“正确”值。

【讨论】：

【解决方案5】：

反对接受的答案，section 4.3.2 of RFC 7231 状态：

服务器应该发送相同的头字段来响应 HEAD 请求，因为如果请求是 GET 则它会发送，除了有效负载头字段（第 3.3 节）

——即Content-Length、Content-Range、Trailer、Transfer-Encoding——

可以省略。

这是even weaker，而不是Paul Dixon's answer 中的注释：

MAY 这个词或形容词“OPTIONAL”表示一个项目是真正的可选。一位供应商可能会选择包含该项目，因为特定的市场需要它，或者因为供应商认为它增强了产品，而其他供应商可能会省略相同的项目。

所以真正的答案是，你不需要包含 Content-Length，但如果你这样做了，你应该给出正确的值。

【讨论】：