带有 HEAD 请求的内容长度标头？

Question

http 规范 介绍了 HEAD< /代码> 请求：

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

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

Answer 1

对我来说，HTTP 1.1 RFC 很漂亮具体的：

内容长度
实体头字段表示实体主体的大小，以十进制表示
发送给接收者的八位字节数，或者，在 HEAD 的情况下
方法，将发送的实体主体的大小
该请求是 GET。

Answer 2

HTTP/1.1 规范的第 14.13 节详细介绍了内容-长度标头，并表示：

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

“SHOULD”一词在 RFC 中具有非常具体的含义：

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

因此，您可能并不总是看到内容长度。通常，您可能看不到任何动态生成的内容，因为这对于服务探索性 HEAD 请求来说可能太昂贵。例如，对 Apache 的静态文件的 HEAD 请求将具有内容长度，但对 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

那里没有内容长度。

Answer 3

是的，HEAD 响应的 Content-Length 应该，但并非总是如此（请参阅 @Paul 的回答）包含 GET 的 Content-Length 值 响应：

Stack Overflow 会：

> 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

Google 不会：

> 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

Answer 4

与已接受的答案相反，RFC 7231 第 4.3.2 节状态：

服务器应该发送与 GET 请求相同的头字段来响应 HEAD 请求，除了有效负载头字段（第 3.3 节）

——也就是说，Content-Length、Content-Range 、预告片和传输编码——

可以省略。

这比 甚至更弱 “https://stackoverflow.com/a/3854983/27358">保罗·迪克森的回答：

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

所以真正的答案是，您不需要包含 Content-Length，但如果包含，则应该给出正确的值。

Answer 5

W3C 的 HTTP 规范 指出：

如果新字段值表明缓存的实体与当前实体不同（如内容长度的更改所示，...

这（对我来说）意味着它应该保存“正确”的值，就像在GET 响应。

Answer 6

根据 2022 年 6 月发布的最新 HTTP 规范 RFC 9110 - HTTP Semantics，

• 第 8.6 节第 6 段：

服务器可以在对 HEAD 请求的响应中发送 Content-Length 标头字段（第 9.3.2 节）；服务器不得在此类响应中发送 Content-Length，除非其字段值等于在同一请求使用 GET 方法时在响应内容中发送的八位字节的十进制数。

• 第 9.3.2 节第 2 段：

服务器应该发送相同的头字段来响应 HEAD 请求，就像请求方法为 GET 时发送的头字段一样。但是，服务器可以省略仅在生成内容时才确定其值的标头字段。例如，一些服务器缓冲对 GET 的动态响应，直到生成最少量的数据，以便它们可以更有效地界定小响应或做出有关内容选择的后期决策。例如，对 GET 的此类响应可能包含 Content-Length 和 Vary 字段，这些字段不是在 HEAD 响应中生成的。这些微小的不一致被认为比生成和丢弃 HEAD 请求的内容更可取，因为通常为了提高效率而请求 HEAD。