Avoiding Content-Length in HEAD response

Question

The Content-Length response header is often expensive to generate for a just HEAD request (e.g. when dealing with dynamically generated resources), but may be essentially "free" after doing the work needed to generate a GET response body.

When it is reasonable to provide a Content-Length (instead of a chunked response) when responding to a GET request, yet unreasonable or slow to calculate the Content-Length for the corresponding HEAD request, is it permissible for the HEAD response to:

• Omit the Content-Length header altogether?
• Respond with Transfer-Encoding: chunked even though GET response would have a Content-Length?

The relevant W3C specification indicates that a HEAD request "SHOULD" (not "MUST") respond with identical headers; is the cleanliness and, admittedly often minor, total transfer size savings of using Content-Length in the GET response worth violating the aforementioned "SHOULD" in the case of HEAD, or is the only reasonable choice to have both responses send a Transfer-Encoding: chunked header?

Answer 1

Thanks to a tip from @julian-reschke, rfc-7231 indicates that:

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.

Per section 3.3 of that same document, the payload header fields consist of:

• Content-Length
• Content-Range
• Trailer
• Transfer-Encoding