title: Can a HTTP library determine the message-body's length without intrinsic knowledge of the request method?
body: <p><strong>During a HTTP request/response, how do you determine the presence and length of the message-body, and in particular, does whatever algorithm is required make use of the request-method as input?</strong></p>
  
  <p>I'm interested in both the request and the response, though
  <a href="https://stackoverflow.com/questions/9145181/http-request-message-body-existence-and-length">this question asks about the requests's message-body's existance and length</a>, and it looks like it should be determinable on headers alone (i.e., using the method specified in <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4" rel="nofollow noreferrer">§4.4 of RFC2616</a>) That's good for the request, but it is similarly possible to do the same for the response?</p>
  
  <p><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4" rel="nofollow noreferrer">RFC2616 §4.4</a> seems to indicate that the same algorithm should get used for the request <em>and</em> the response (as it's talking in generic terms of message-body), so this would seem  to indicate it <em>can</em> be done generically.</p>
  
  <p>However, the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4" rel="nofollow noreferrer">HEAD method</a> sticks out like a sore thumb here: Content-Length is sent back as part of the headers during the response, but no body will be.</p>
  
  <p>Is HEAD special, and the only special method? Or can an <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1" rel="nofollow noreferrer">extension method</a> have a similar behavior, and thus I actually do need to know — for each method — whether that method requires special handling. (And thus, extension methods can't be used unless pre-negotiated outside HTTP.)</p>