Content-Length header with HEAD requests?

Question

The http spec says about the HEAD request:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request.

Should the response to a HEAD request contain a Content-Length header? Should it be the value which would be returned on a GET request, even if there is no response body? Or should the Content-Length be 0?

Hereafter

Answer 1

To me it looks like the HTTP 1.1 RFC is pretty specific:

The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

Epinasty

Interestingly enough, curl tells you that the body is missing... they may not "know" that the method is a HEAD when reading the reply and assume that the body is missing. – Oarsman

curl --head behaves better than curl -X HEAD. – Mien

wi don't get what it says, can you say it simpler? – Pneumatometer

@deadManN in HEAD request the Content-Length should be the same as it would have been in a GET request even though there's no actual body. – Epinasty

No longer relevant as the RFC 2616 was superseded by RFC 7230-7237. Section 4.3.2 of RFC 7231 states The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. Payload header fields defined in section 3.3 are Content-Length, Content-Range, Trailer and Transfer-Encoding. – Hanley

Answer 2

Section 14.13 of the HTTP/1.1 spec detailed the Content-Length header, and says this:

Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.

The word 'SHOULD' has a very specific meaning in RFCs:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, you may not always see a Content-Length. Typically you might not see it for any content which is dynamically generated, since that might be too expensive to service an exploratory HEAD request. For example, a HEAD request to Apache for a static file will have a Content-Length, but a request for a PHP script may not.

For example, try this very website...

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

No content-length there.

Cream

Notably, you also won't see Content-Length if it's a Transfer-Encoding: chunked response. – Somnambulate

@PaulDixon Could you shed some light on this thread? Thx. #34290703 – Repine

A HEAD request to google.com will now (11th of Jan 2016) return Content-Length as well. – Unfavorable

ah well, that example had a good 6 year run! Have changed it to use stackoverflow.com :) – Cream

I think this example doesn't work anymore either; a HEAD request to stackoverflow.com now returns Content-Length. – Grettagreuze

So how do you actually force nginx to send the Content-Length header on HEAD requests? I need to do it in my application. – Dercy

@PaulDixon +1 "Typically you might not see it for any content which is dynamically generated, since that might be too expensive to service an exploratory HEAD request." – Concerto

No longer relevant as the RFC 2616 was superseded by RFC 7230-7237. Section 4.3.2 of RFC 7231 states The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. Payload header fields defined in section 3.3 are Content-Length, Content-Range, Trailer and Transfer-Encoding. – Hanley

Answer 3

Yes, the Content-Length of a HEAD response SHOULD, but not always does (see @Paul's answer) include the Content-Length value of a GET response:

Stack Overflow does:

> 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 doesn't:

> 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

Celery

I think you're seeing the Content length of the error message you get for not using HTTP/1.0. If you send a proper 1.0 HEAD request, you do not get a content length. I tried this on a local apache instance also, and again, no content length was returned. – Cream

@Paul: Fixed my malformed request. I still get a Content-Length however, as I should. Even when using HTTP/1.0: i.imgur.com/iq9bm.jpg – Celery

Yes, the StackOverflow IIS servers do send it. Google doesn't though. – Cream

@Paul: Interesting. Google doesn't send it for 200 responses though. I get it for all the other return codes: 301, 302, 400, etc. +1 for finding the proper definition of "SHOULD" :) – Celery

How can you add the header in nginx? – Dercy

Answer 4

The HTTP-spec at W3C states:

If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, ...

Which (to me) means it should hold the "correct" value as you would in a GET response.

Tavey

Answer 5

Contra the accepted answer, section 4.3.2 of RFC 7231 states:

The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3)

—which is to say, Content-Length, Content-Range, Trailer, and Transfer-Encoding—

MAY be omitted.

This is even weaker than the note on SHOULD in Paul Dixon's answer:

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

So the real answer is, you don't need to include Content-Length, but if you do, you should give the correct value.

Lavoie

Answer 6

According to RFC 9110 - HTTP Semantics, the latest HTTP specification published in June 2022,

• section 8.6, paragraph 6:

A server MAY send a Content-Length header field in a response to a HEAD request (Section 9.3.2); a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a response if the same request had used the GET method.

• section 9.3.2, paragraph 2:

The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain Content-Length and Vary fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency.

Fireresistant