HTTP规范 中关于 HEAD
请求的说明如下:
HEAD
方法与GET
方法相同,除了服务器在响应中不得返回消息正文。响应HEAD
请求时 HTTP 头中包含的元信息应该与响应GET
请求时发送的信息相同.
HEAD
请求的响应是否应包含 Content-Length
头?它是否应该是在没有响应正文的情况下 GET
请求将返回的值?还是应该为 0?
HTTP规范 中关于 HEAD
请求的说明如下:
HEAD
方法与GET
方法相同,除了服务器在响应中不得返回消息正文。响应HEAD
请求时 HTTP 头中包含的元信息应该与响应GET
请求时发送的信息相同.
HEAD
请求的响应是否应包含 Content-Length
头?它是否应该是在没有响应正文的情况下 GET
请求将返回的值?还是应该为 0?
在我看来,HTTP 1.1 RFC非常明确:
Content-Length实体头字段表示发送给接收方的实体正文的大小,以十进制字节数表示。 对于HEAD方法,则表示如果请求是GET,则会发送哪些实体正文的大小。
HTTP/1.1规范第14.13节详细说明了Content-Length头字段,并指出:
应用程序应该使用此字段来指示消息正文的传输长度,除非根据第4.4节的规则禁止这样做。
在RFC中,“SHOULD”这个词有非常特定的含义:
- SHOULD 这个词或形容词“建议性的(RECOMMENDED)”表示在特定情况下存在有效理由忽略某一项,但在选择不同课程之前必须充分了解和仔细权衡全部影响。
因此,您可能并不总是看到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
。 - RobHEAD
请求也会返回Content-Length
。 - zponHEAD
请求会返回Content-Length
。 - Nick Bartlett是的,HEAD
响应的Content-Length
应该 包含GET
响应的Content-Length
值(请参见@Paul's answer),但并不总是这样。
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
谷歌不会:
> 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
Content-Length
,这是应该的。即使使用HTTP/1.0
也是如此:http://i.imgur.com/iq9bm.jpg - Daniel Vassallo与被接受的答案相反,RFC 7231的4.3.2节指出:
服务器应该在响应HEAD请求时发送与GET请求相同的标头字段,除了有效载荷标头字段(第3.3节)
也就是说,Content-Length、Content-Range、Trailer和Transfer-Encoding可能会被省略。
这比Paul Dixon's answer中关于SHOULD的说明更加宽松:
所以真正的答案是,您不需要包含Content-Length,但如果您这样做,应该给出正确的值。
- MAY 这个词或形容词“OPTIONAL”表示该项是可选的。一个供应商可以选择包括该项,因为某个特定市场需要它或者因为供应商认为它能增强产品,而另一个供应商则可以省略相同的项。
服务器应该在响应HEAD请求时发送与GET请求相同的头字段。然而,服务器可以省略仅在生成内容时才确定值的头字段。例如,一些服务器会缓冲对GET的动态响应,直到生成了最小数量的数据,以便更有效地分隔小型响应或在内容选择方面做出晚期决策。这样对GET的响应可能包含Content-Length和Vary字段,但这些字段不会在HEAD响应中生成。这些轻微的不一致性被认为比为了HEAD请求而生成并丢弃内容更可取,因为通常请求HEAD是为了提高效率。服务器可以在响应HEAD请求(第9.3.2节)中发送Content-Length头字段;除非其字段值等于使用GET方法时响应内容将发送的八位字节的十进制数,否则服务器不得在此类响应中发送Content-Length。
curl --head
的表现比curl -X HEAD
更好。 - Beni Cherniavsky-PaskinHEAD
请求中,@deadManN要求Content-Length
应该与GET
请求中的长度相同,即使实际上没有正文。 - nietakiContent-Length
,Content-Range
,Trailer
和Transfer-Encoding
。 - Piotr Dobrogost