title: Avoiding Content-Length in HEAD response
body: <p>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.</p>
  
  <p>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:</p>
  
  <ul>
  <li>Omit the Content-Length header altogether?</li>
  <li>Respond with <code>Transfer-Encoding: chunked</code> even though GET response would have a <code>Content-Length</code>?</li>
  </ul>
  
  <p>The <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4" rel="noreferrer">relevant W3C specification</a> indicates that a HEAD request "SHOULD" (<em>not</em> "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 <code>Transfer-Encoding: chunked</code> header?</p>